deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47439
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work

When the ksz module is installed and removed using rmmod, kernel crashes
with null pointer dereferrence error. During rmmod, ksz_switch_remove
function tries to cancel the mib_read_workqueue using
cancel_delayed_work_sync routine and unregister switch from dsa.

During dsa_unregister_switch it calls ksz_mac_link_down, which in turn
reschedules the workqueue since mib_interval is non-zero.
Due to which queue executed after mib_interval and it tries to access
dp->slave. But the slave is unregistered in the ksz_switch_remove
function. Hence kernel crashes.

To avoid this crash, before canceling the workqueue, resetted the
mib_interval to 0.

v1 -> v2:
-Removed the if condition in ksz_mib_read_work
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/383239a33cf29ebee9ce0d4e0e5c900b77a16148; https://git.kernel.org/stable/c/ef1100ef20f29aec4e62abeccdb5bdbebba1e378; https://git.kernel.org/stable/c/f2e1de075018cf71bcd7d628e9f759cb8540b0c3
CVE: CVE-2021-47440
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

net: encx24j600: check error in devm_regmap_init_encx24j600

devm_regmap_init may return error which caused by like out of memory,
this will results in null pointer dereference later when reading
or writing register:

general protection fault in encx24j600_spi_probe
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000090-0x[PII_REDACTED]000097]
CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540
Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00
RSP: 0018:ffffc900010476b8 EFLAGS: 00010207
RAX: dffffc[PII_REDACTED] RBX: fffffffffffffff4 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffff888002de0000 RDI: [PII_REDACTED]
RBP: ffff888013c9a000 R08: [PII_REDACTED] R09: fffffbfff3f9cc6a
R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: [PII_REDACTED]
R13:[PII_REDACTED]00000a R14: ffff888013c9af54 R15: ffff888013c9ad08
FS:  00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4:[PII_REDACTED]770ef0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
PKRU: 55555554
Call Trace:
 encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459
 spi_probe drivers/spi/spi.c:397
 really_probe drivers/base/dd.c:517
 __driver_probe_device drivers/base/dd.c:751
 driver_probe_device drivers/base/dd.c:782
 __device_attach_driver drivers/base/dd.c:899
 bus_for_each_drv drivers/base/bus.c:427
 __device_attach drivers/base/dd.c:971
 bus_probe_device drivers/base/bus.c:487
 device_add drivers/base/core.c:3364
 __spi_add_device drivers/spi/spi.c:599
 spi_add_device drivers/spi/spi.c:641
 spi_new_device drivers/spi/spi.c:717
 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d[PII_REDACTED]0568e85e]
 dev_attr_store drivers/base/core.c:2074
 sysfs_kf_write fs/sysfs/file.c:139
 kernfs_fop_write_iter fs/kernfs/file.c:300
 new_sync_write fs/read_write.c:508 (discriminator 4)
 vfs_write fs/read_write.c:594
 ksys_write fs/read_write.c:648
 do_syscall_64 arch/x86/entry/common.c:50
 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113

Add error check in devm_regmap_init_encx24j600 to avoid this situation.
CVSS Score: 2.3 (LOW)
CWE: CWE-476
References: https://git.kernel.org/stable/c/322c0e53496309e634d9db7349678eaad1d25b55; https://git.kernel.org/stable/c/4c2eb80fc90b05559ce6ed1b8dfb2348420b5644; https://git.kernel.org/stable/c/5e5494e6fc8a29c927e0478bec4a078a40da8901
CVE: CVE-2021-47442
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

NFC: digital: fix possible memory leak in digital_in_send_sdd_req()

'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/071bdef36391958c89af5fa2172f691b31baa212; https://git.kernel.org/stable/c/291c932fc3692e4d211a445ba8aa35663831bac7; https://git.kernel.org/stable/c/2bde4aca56db9fe25405d39ddb062531493a65db
CVE: CVE-2021-47443
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()

'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3f2960b39f22e26cf8addae93c3f5884d1c183c9; https://git.kernel.org/stable/c/429054ec51e648d241a7e0b465cf44f6633334c5; https://git.kernel.org/stable/c/564249219e5b5673a8416b5181875d828c3f1e8c
CVE: CVE-2021-47444
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read

In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.

Let's fix this by adding a bounds check.

This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09f3946bb452918dbfb1982add56f9ffaae393dc; https://git.kernel.org/stable/c/97794170b696856483f74b47bfb6049780d2d3a0; https://git.kernel.org/stable/c/a7b45024f66f9ec769e8dbb1a51ae83cd05929c7
CVE: CVE-2021-47445
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix null pointer dereference on pointer edp

The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.

Addresses-Coverity: ("Dereference before null check")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0cd063aa0a09822cc1620fc59a67fe2f9f6338ac; https://git.kernel.org/stable/c/2133c4fc8e1348dcb752f267a143fe2254613b34; https://git.kernel.org/stable/c/46c8ddede0273d1d132beefa9de8b820326982be
CVE: CVE-2021-47446
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/a4xx: fix error handling in a4xx_gpu_init()

This code returns 1 on error instead of a negative error.  It leads to
an Oops in the caller.  A second problem is that the check for
"if (ret != -ENODATA)" cannot be true because "ret" is set to 1.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3962d626eb3e3b23ebb2e2a61537fa764acbfe11; https://git.kernel.org/stable/c/980d74e7d03ccf2eaa11d133416946bd880c7c08; https://git.kernel.org/stable/c/3962d626eb3e3b23ebb2e2a61537fa764acbfe11
CVE: CVE-2021-47447
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/a3xx: fix error handling in a3xx_gpu_init()

These error paths returned 1 on failure, instead of a negative error
code.  This would lead to an Oops in the caller.  A second problem is
that the check for "if (ret != -ENODATA)" did not work because "ret" was
set to 1.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3eda901995371d390ef82d0b6462f4ea8efbcfdf; https://git.kernel.org/stable/c/d59e44e7821a8f2bb6f2e846b9167397a5f01608; https://git.kernel.org/stable/c/3eda901995371d390ef82d0b6462f4ea8efbcfdf
CVE: CVE-2021-47450
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Fix host stage-2 PGD refcount

The KVM page-table library refcounts the pages of concatenated stage-2
PGDs individually. However, when running KVM in protected mode, the
host's stage-2 PGD is currently managed by EL2 as a single high-order
compound page, which can cause the refcount of the tail pages to reach 0
when they shouldn't, hence corrupting the page-table.

Fix this by introducing a new hyp_split_page() helper in the EL2 page
allocator (matching the kernel's split_page() function), and make use of
it from host_s2_zalloc_pages_exact().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1d58a17ef54599506d44c45ac95be27273a4d2b1; https://git.kernel.org/stable/c/b372264c66ef78f2cab44e877fbd765ad6d24c39; https://git.kernel.org/stable/c/1d58a17ef54599506d44c45ac95be27273a4d2b1
CVE: CVE-2021-47451
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value

Currently, when the rule related to IDLETIMER is added, idletimer_tg timer
structure is initialized by kmalloc on executing idletimer_tg_create
function. However, in this process timer->timer_type is not defined to
a specific value. Thus, timer->timer_type has garbage value and it occurs
kernel panic. So, this commit fixes the panic by initializing
timer->timer_type using kzalloc instead of kmalloc.

Test commands:
    # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test
    $ cat /sys/class/xt_idletimer/timers/test
      Killed

Splat looks like:
    BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70
    Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917
    CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     dump_stack_lvl+0x6e/0x9c
     kasan_report.cold+0x112/0x117
     ? alarm_expires_remaining+0x49/0x70
     __asan_load8+0x86/0xb0
     alarm_expires_remaining+0x49/0x70
     idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d]
     dev_attr_show+0x3c/0x60
     sysfs_kf_seq_show+0x11d/0x1f0
     ? device_remove_bin_file+0x20/0x20
     kernfs_seq_show+0xa4/0xb0
     seq_read_iter+0x29c/0x750
     kernfs_fop_read_iter+0x25a/0x2c0
     ? __fsnotify_parent+0x3d1/0x570
     ? iov_iter_init+0x70/0x90
     new_sync_read+0x2a7/0x3d0
     ? __x64_sys_llseek+0x230/0x230
     ? rw_verify_area+0x81/0x150
     vfs_read+0x17b/0x240
     ksys_read+0xd9/0x180
     ? vfs_write+0x460/0x460
     ? do_syscall_64+0x16/0xc0
     ? lockdep_hardirqs_on+0x79/0x120
     __x64_sys_read+0x43/0x50
     do_syscall_64+0x3b/0xc0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f0cdc819142
    Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
    RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
    RAX: ffffffffffffffda RBX: [PII_REDACTED] RCX: 00007f0cdc819142
    RDX: [PII_REDACTED] RSI: 00007f0cdc032000 RDI: [PII_REDACTED]
    RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: [PII_REDACTED]
    R10: [PII_REDACTED] R11: [PII_REDACTED] R12: 00005607e9ee31f0
    R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/2a670c323055282c9b72794a491d53cef86bbeaf; https://git.kernel.org/stable/c/902c0b1887522a099aa4e1e6b4b476c2fe5dd13e; https://git.kernel.org/stable/c/cae7cab804c943d723d52724a3aeb07a3f4a2650
CVE: CVE-2021-47452
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: skip netdev events generated on netns removal

syzbot reported following (harmless) WARN:

 WARNING: CPU: 1 PID: 2648 at net/netfilter/core.c:468
  nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [inline]
  nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [inline]
  __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524
  nft_netdev_event net/netfilter/nft_chain_filter.c:351 [inline]
  nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382

reproducer:
unshare -n bash -c 'ip link add br0 type bridge; nft add table netdev t ; \
 nft add chain netdev t ingress \{ type filter hook ingress device "br0" \
 priority 0\; policy drop\; \}'

Problem is that when netns device exit hooks create the UNREGISTER
event, the .pre_exit hook for nf_tables core has already removed the
base hook.  Notifier attempts to do this again.

The need to do base hook unregister unconditionally was needed in the past,
because notifier was last stage where reg->dev dereference was safe.

Now that nf_tables does the hook removal in .pre_exit, this isn't
needed anymore.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/68a3765c659f809dcaac20030853a054646eb739; https://git.kernel.org/stable/c/90c7c58aa2bd02c65a4c63b7dfe0b16eab12cf9f; https://git.kernel.org/stable/c/68a3765c659f809dcaac20030853a054646eb739
CVE: CVE-2021-47453
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Avoid crash from unnecessary IDA free

In the remove path, there is an attempt to free the aux_idx IDA whether
it was allocated or not.  This can potentially cause a crash when
unloading the driver on systems that do not initialize support for RDMA.
But, this free cannot be gated by the status bit for RDMA, since it is
allocated if the driver detects support for RDMA at probe time, but the
driver can enter into a state where RDMA is not supported after the IDA
has been allocated at probe time and this would lead to a memory leak.

Initialize aux_idx to an invalid value and check for a valid value when
unloading to determine if an IDA free is necessary.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/73e30a62b19b9fbb4e6a3465c59da186630d5f2e; https://git.kernel.org/stable/c/777682e59840e24e6c5672197e6ffbcf4bff823b; https://git.kernel.org/stable/c/73e30a62b19b9fbb4e6a3465c59da186630d5f2e
CVE: CVE-2021-47454
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/smp: do not decrement idle task preempt count in CPU offline

With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we
get:

BUG: scheduling while atomic: swapper/1/0/0x00000000
no locks held by swapper/1/0.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ #100
Call Trace:
 dump_stack_lvl+0xac/0x108
 __schedule_bug+0xac/0xe0
 __schedule+0xcf8/0x10d0
 schedule_idle+0x3c/0x70
 do_idle+0x2d8/0x4a0
 cpu_startup_entry+0x38/0x40
 start_secondary+0x2ec/0x3a0
 start_secondary_prolog+0x10/0x14

This is because powerpc's arch_cpu_idle_dead() decrements the idle task's
preempt count, for reasons explained in commit a7c2bb8279d2 ("powerpc:
Re-enable preemption before cpu_die()"), specifically "start_secondary()
expects a preempt_count() of 0."

However, since commit 2c669ef6979c ("powerpc/preempt: Don't touch the idle
task's preempt_count during hotplug") and commit f1a0a376ca0c ("sched/core:
Initialize the idle task with preemption disabled"), that justification no
longer holds.

The idle task isn't supposed to re-enable preemption, so remove the
vestigial preempt_enable() from the CPU offline path.

Tested with pseries and powernv in qemu, and pseries on PowerVM.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ea0b497a7a2fff6a4b7090310c9f52c91975934; https://git.kernel.org/stable/c/53770a411559cf7bc0906d1df319cc533d2f4f58; https://git.kernel.org/stable/c/787252a10d9422f3058df9a4821f389e5326c440
CVE: CVE-2021-47455
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: Fix possible memory leak in ptp_clock_register()

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88800906c618 (size 8):
  comm "i2c-idt82p33931", pid 4421, jiffies[PII_REDACTED] (age 13.188s)
  hex dump (first 8 bytes):
    70 74 70 30 00 00 00 00                          ptp0....
  backtrace:
    [<[PII_REDACTED]2ed458>] __kmalloc_track_caller+0x19f/0x3a0
    [<[PII_REDACTED]f6e2ff>] kvasprintf+0xb5/0x150
    [<[PII_REDACTED]aae54f>] kvasprintf_const+0x60/0x190
    [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
    [<000000004e35abdd>] dev_set_name+0xc0/0x100
    [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
    [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]

When posix_clock_register() returns an error, the name allocated
in dev_set_name() will be leaked, the put_device() should be used
to give up the device reference, then the name will be freed in
kobject_cleanup() and other memory will be freed in ptp_clock_release().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4225fea1cb28370086e17e82c0f69bec2779dca0; https://git.kernel.org/stable/c/95c0a0c5ec8839f8f21672be786e87a100319ca8; https://git.kernel.org/stable/c/f1c96d8085588e1b997a96214b409ac3be20b524
CVE: CVE-2021-47456
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

can: peak_pci: peak_pci_remove(): fix UAF

When remove the module peek_pci, referencing 'chan' again after
releasing 'dev' will cause UAF.

Fix this by releasing 'dev' later.

The following log reveals it:

[   35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537
[   35.965513 ] Call Trace:
[   35.965718 ]  dump_stack_lvl+0xa8/0xd1
[   35.966028 ]  print_address_description+0x87/0x3b0
[   35.966420 ]  kasan_report+0x172/0x1c0
[   35.966725 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.967137 ]  ? trace_irq_enable_rcuidle+0x10/0x170
[   35.967529 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.967945 ]  __asan_report_load8_noabort+0x14/0x20
[   35.968346 ]  peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.968752 ]  pci_device_remove+0xa9/0x250
CVSS Score: 8.4 (HIGH)
CWE: CWE-416, CWE-467
References: https://git.kernel.org/stable/c/0e5afdc2315b0737edcf55bede4ee1640d2d464d; https://git.kernel.org/stable/c/1248582e47a9f7ce0ecd156c39fc61f8b6aa3699; https://git.kernel.org/stable/c/1c616528ba4aeb1125a06b407572ab7b56acae38
CVE: CVE-2021-47457
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible()

Using wait_event_interruptible() to wait for complete transmission,
but do not check the result of wait_event_interruptible() which can be
interrupted. It will result in TX buffer has multiple accessors and
the later process interferes with the previous process.

Following is one of the problems reported by syzbot.

=============================================================
WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0
Call Trace:
 <IRQ>
 ? isotp_setsockopt+0x390/0x390
 __hrtimer_run_queues+0xb8/0x610
 hrtimer_run_softirq+0x91/0xd0
 ? rcu_read_lock_sched_held+0x4d/0x80
 __do_softirq+0xe8/0x553
 irq_exit_rcu+0xf8/0x100
 sysvec_apic_timer_interrupt+0x9e/0xc0
 </IRQ>
 asm_sysvec_apic_timer_interrupt+0x12/0x20

Add result check for wait_event_interruptible() in isotp_sendmsg()
to avoid multiple accessers for tx buffer.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/053bc12df0d6097c1126d0e14fa778a0a8faeb64; https://git.kernel.org/stable/c/9acf636215a6ce9362fe618e7da4913b8bfe84c8; https://git.kernel.org/stable/c/a76abedd2be3926d6deba236a935c7f98abf9110
CVE: CVE-2021-47458
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: mount fails with buffer overflow in strlen

Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
trace below.  Problem seems to be that strings for cluster stack and
cluster name are not guaranteed to be null terminated in the disk
representation, while strlcpy assumes that the source string is always
null terminated.  This causes a read outside of the source string
triggering the buffer overflow detection.

  detected buffer overflow in strlen
  ------------[ cut here ]------------
  kernel BUG at lib/string.c:1149!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
    Debian 5.14.6-2
  RIP: 0010:fortify_panic+0xf/0x11
  ...
  Call Trace:
   ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
   ocfs2_fill_super+0x359/0x19b0 [ocfs2]
   mount_bdev+0x185/0x1b0
   legacy_get_tree+0x27/0x40
   vfs_get_tree+0x25/0xb0
   path_mount+0x454/0xa20
   __x64_sys_mount+0x103/0x140
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0e677ea5b7396f715a76b6b0ef441430e4c4b57f; https://git.kernel.org/stable/c/232ed9752510de4436468b653d145565669c8498; https://git.kernel.org/stable/c/4b74ddcc22ee6455946e80a9c4808801f8f8561e
CVE: CVE-2021-47459
Published: 2024-05-22
Description: In the Linux kernel, the following vulnerability has been resolved:

can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv

It will trigger UAF for rx_kref of j1939_priv as following.

        cpu0                                    cpu1
j1939_sk_bind(socket0, ndev0, ...)
j1939_netdev_start
                                        j1939_sk_bind(socket1, ndev0, ...)
                                        j1939_netdev_start
j1939_priv_set
                                        j1939_priv_get_by_ndev_locked
j1939_jsk_add
.....
j1939_netdev_stop
kref_put_lock(&priv->rx_kref, ...)
                                        kref_get(&priv->rx_kref, ...)
                                        REFCOUNT_WARN("addition on 0;...")

====================================================
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0
RIP: 0010:refcount_warn_saturate+0x169/0x1e0
Call Trace:
 j1939_netdev_start+0x68b/0x920
 j1939_sk_bind+0x426/0xeb0
 ? security_socket_bind+0x83/0xb0

The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to
protect.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/6e8811707e2df0c6ba920f0cad3a3bca7b42132f; https://git.kernel.org/stable/c/864e77771a24c877aaf53aee019f78619cbcd668; https://git.kernel.org/stable/c/a0e47d2833b4f65e6c799f28c6b636d36b8b936d