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

btrfs: fix memory ordering between normal and ordered work functions

Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.

This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:

    pc : submit_compressed_extents+0x38/0x3d0
    lr : async_cow_submit+0x50/0xd0
    sp : ffff800015d4bc20

    <registers omitted for brevity>

    Call trace:
     submit_compressed_extents+0x38/0x3d0
     async_cow_submit+0x50/0xd0
     run_ordered_work+0xc8/0x280
     btrfs_work_helper+0x98/0x250
     process_one_work+0x1f0/0x4ac
     worker_thread+0x188/0x504
     kthread+0x110/0x114
     ret_from_fork+0x10/0x18

Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.
CVSS Score: 6.3 (MEDIUM)
References: https://git.kernel.org/stable/c/45da9c1767ac31857df572f0a909fbe88fd5a7e9; https://git.kernel.org/stable/c/47e6f9f[PII_REDACTED]9042010f3a77579e9dc61ff; https://git.kernel.org/stable/c/637d652d351fd4f263ef302dc52f3971d314e500
CVE: CVE-2021-47190
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

perf bpf: Avoid memory leak from perf_env__insert_btf()

perf_env__insert_btf() doesn't insert if a duplicate BTF id is
encountered and this causes a memory leak. Modify the function to return
a success/error value and then free the memory if insertion didn't
happen.

v2. Adds a return -1 when the insertion error occurs in
    perf_env__fetch_btf. This doesn't affect anything as the result is
    never checked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/11589d3144bc4e272e0aae46ce8156162e99babc; https://git.kernel.org/stable/c/4924b1f7c46711762fd0e65c135ccfbcfd6ded1f; https://git.kernel.org/stable/c/642fc22210a5e59d40b1e4d56d21ec3effd401f2
CVE: CVE-2021-47191
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()

The following warning was observed running syzkaller:

[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;
[ 3813.830724]    program syz-executor not setting count and/or reply_len properly
[ 3813.836956] ==================================================================
[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0
[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549
[ 3813.846612] Call Trace:
[ 3813.846995]  dump_stack+0x108/0x15f
[ 3813.847524]  print_address_description+0xa5/0x372
[ 3813.848243]  kasan_report.cold+0x236/0x2a8
[ 3813.849439]  check_memory_region+0x240/0x270
[ 3813.850094]  memcpy+0x30/0x80
[ 3813.850553]  sg_copy_buffer+0x157/0x1e0
[ 3813.853032]  sg_copy_from_buffer+0x13/0x20
[ 3813.853660]  fill_from_dev_buffer+0x135/0x370
[ 3813.854329]  resp_readcap16+0x1ac/0x280
[ 3813.856917]  schedule_resp+0x41f/0x1630
[ 3813.858203]  scsi_debug_queuecommand+0xb32/0x17e0
[ 3813.862699]  scsi_dispatch_cmd+0x330/0x950
[ 3813.863329]  scsi_request_fn+0xd8e/0x1710
[ 3813.863946]  __blk_run_queue+0x10b/0x230
[ 3813.864544]  blk_execute_rq_nowait+0x1d8/0x400
[ 3813.865220]  sg_common_write.isra.0+0xe61/0x2420
[ 3813.871637]  sg_write+0x6c8/0xef0
[ 3813.878853]  __vfs_write+0xe4/0x800
[ 3813.883487]  vfs_write+0x17b/0x530
[ 3813.884008]  ksys_write+0x103/0x270
[ 3813.886268]  __x64_sys_write+0x77/0xc0
[ 3813.886841]  do_syscall_64+0x106/0x360
[ 3813.887415]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This issue can be reproduced with the following syzkaller log:

r0 = openat(0xffffffffffffff9c, &(0x7f[PII_REDACTED])='./file0\x00', 0x26e1, 0x0)
r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f[PII_REDACTED])='fd/3\x00')
open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)
r2 = syz_open_dev$sg(&(0x7f[PII_REDACTED]), 0x0, 0x40782)
write$binfmt_aout(r2, &(0x7f[PII_REDACTED])=ANY=[@ANYBLOB="00000000deff[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]0047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)

In resp_readcap16() we get "int alloc_len" value [PII_REDACTED], and then pass
the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This
leads to OOB in sg_copy_buffer().

To solve this issue, define alloc_len as u32.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a; https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c; https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999
CVE: CVE-2021-47192
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: core: sysfs: Fix hang when device state is set via sysfs

This fixes a regression added with:

commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after
offlinining device")

The problem is that after iSCSI recovery, iscsid will call into the kernel
to set the dev's state to running, and with that patch we now call
scsi_rescan_device() with the state_mutex held. If the SCSI error handler
thread is just starting to test the device in scsi_send_eh_cmnd() then it's
going to try to grab the state_mutex.

We are then stuck, because when scsi_rescan_device() tries to send its I/O
scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery()
which will return true (the host state is still in recovery) and I/O will
just be requeued. scsi_send_eh_cmnd() will then never be able to grab the
state_mutex to finish error handling.

To prevent the deadlock move the rescan-related code to after we drop the
state_mutex.

This also adds a check for if we are already in the running state. This
prevents extra scans and helps the iscsid case where if the transport class
has already onlined the device during its recovery process then we don't
need userspace to do it again plus possibly block that daemon.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f; https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73; https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
CVE: CVE-2021-47193
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Fix memory leak during rmmod

Driver failed to release all memory allocated. This would lead to memory
leak during driver removal.

Properly free memory when the module is removed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0c4398f2ee030d5753f6b0ad83f0ed9077851d9a; https://git.kernel.org/stable/c/269a4311b15f68d24e816f43f123888f241ed13d; https://git.kernel.org/stable/c/51e6ed83bb4ade7c360551fa4ae55c4eacea354b
CVE: CVE-2021-47194
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

cfg80211: call cfg80211_stop_ap when switch from P2P_GO type

If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
does not call the cleanup cfg80211_stop_ap(), this leads to the
initialization of in-use data. For example, this path re-init the
sdata->assigned_chanctx_list while it is still an element of
assigned_vifs list, and makes that linked list corrupt.
CVSS Score: 7.8 (HIGH)
CWE: CWE-665
References: https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc; https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21; https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13
CVE: CVE-2021-47195
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: fix use-after-free of the add_lock mutex

Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on
SPI buses") introduced a per-controller mutex. But mutex_unlock() of
said lock is called after the controller is already freed:

  spi_unregister_controller(ctlr)
  -> put_device(&ctlr->dev)
    -> spi_controller_release(dev)
  -> mutex_unlock(&ctrl->add_lock)

Move the put_device() after the mutex_unlock().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/11eab327a2a8bd36c38afbff920ae1bd45588dd4; https://git.kernel.org/stable/c/37330f37f6666c7739a44b2b6b95b047ccdbed2d; https://git.kernel.org/stable/c/54c2c96eafcfd242e52e932ab54ace4784efe1dd
CVE: CVE-2021-47196
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Set send and receive CQ before forwarding to the driver

Preset both receive and send CQ pointers prior to call to the drivers and
overwrite it later again till the mlx4 is going to be changed do not
overwrite ibqp properties.

This change is needed for mlx5, because in case of QP creation failure, it
will go to the path of QP destroy which relies on proper CQ pointers.

 BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib]
 Write of size 8 at addr ffff8880064c55c0 by task a.out/246

 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Call Trace:
  dump_stack_lvl+0x45/0x59
  print_address_description.constprop.0+0x1f/0x140
  kasan_report.cold+0x83/0xdf
  create_qp.cold+0x164/0x16e [mlx5_ib]
  mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib]
  create_qp.part.0+0x45b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Allocated by task 246:
  kasan_save_stack+0x1b/0x40
  __kasan_kmalloc+0xa4/0xd0
  create_qp.part.0+0x92/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Freed by task 246:
  kasan_save_stack+0x1b/0x40
  kasan_set_track+0x1c/0x30
  kasan_set_free_info+0x20/0x30
  __kasan_slab_free+0x10c/0x150
  slab_free_freelist_hook+0xb4/0x1b0
  kfree+0xe7/0x2a0
  create_qp.part.0+0x52b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/6cd7397d01c4a3e[PII_REDACTED]9e4f114f0aa5fa0; https://git.kernel.org/stable/c/b70e072feffa0ba5c41a99b9524b9878dee7748e; https://git.kernel.org/stable/c/6cd7397d01c4a3e[PII_REDACTED]9e4f114f0aa5fa0
CVE: CVE-2021-47197
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove()

Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds
to rest of destroy operations. mlx5_core_destroy_cq() could be called again
by user and cause additional call of mlx5_debug_cq_remove().
cq->dbg was not nullify in previous call and cause the crash.

Fix it by nullify cq->dbg pointer after removal.

Also proceed to destroy operations only if FW return 0
for MLX5_CMD_OP_DESTROY_CQ command.

general protection fault, probably for non-canonical address 0x[PII_REDACTED]058: 0000 [#1] SMP PTI
CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:lockref_get+0x1/0x60
Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02
00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17
48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48
RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206
RAX: [PII_REDACTED] RBX: ffff888107d5f458 RCX: 00000000fffffffe
RDX:[PII_REDACTED]02c2b0 RSI: ffffffff8155e2e0 RDI: [PII_REDACTED]
RBP: ffff888137dd7a88 R08: [PII_REDACTED] R09: ffff8881144a9f88
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff8881141d4000
R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0
FS:  00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000)
knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 000055b4500f4380 CR3:[PII_REDACTED]f7a003 CR4:[PII_REDACTED]170ea0
Call Trace:
  simple_recursive_removal+0x33/0x2e0
  ? debugfs_remove+0x60/0x60
  debugfs_remove+0x40/0x60
  mlx5_debug_cq_remove+0x32/0x70 [mlx5_core]
  mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core]
  devx_obj_cleanup+0x151/0x330 [mlx5_ib]
  ? __pollwait+0xd0/0xd0
  ? xas_load+0x5/0x70
  ? xa_load+0x62/0xa0
  destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs]
  uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs]
  uobj_destroy+0x54/0xa0 [ib_uverbs]
  ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs]
  ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs]
  ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs]
  __x64_sys_ioctl+0x3e4/0x8e0
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2ae[PII_REDACTED]6a13a9fe3f0b4b6ec0070aa408a; https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026; https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2
CVE: CVE-2021-47198
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine

An error is detected with the following report when unloading the driver:
  "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"

The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the
flag is not cleared upon completion of the login.

This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set
to LPFC_RPI_ALLOW_ERROR.  This results in a use after free access when used
as an rpi_ids array index.

Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/79b20beccea3a3938a8500acef4e6b9d7c66142f; https://git.kernel.org/stable/c/dbebf865b3239595c1d4dba063b122862583b52a; https://git.kernel.org/stable/c/79b20beccea3a3938a8500acef4e6b9d7c66142f
CVE: CVE-2021-47199
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: CT, Fix multiple allocations and memleak of mod acts

CT clear action offload adds additional mod hdr actions to the
flow's original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.

Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.

Also the driver never releases the allocated mod hdr actions and
causing a memleak.

Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().

 backtrace:
    [<[PII_REDACTED]16e2f3>] krealloc+0x83/0xd0
    [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [<[PII_REDACTED]0ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [<[PII_REDACTED]c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
    [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/486e8de6e233ff[PII_REDACTED]c6259d1cb538653b; https://git.kernel.org/stable/c/806401c20a0f9c51b6c8fd7035671e6ca841f6c2; https://git.kernel.org/stable/c/486e8de6e233ff[PII_REDACTED]c6259d1cb538653b
CVE: CVE-2021-47200
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap

drm_gem_ttm_mmap() drops a reference to the gem object on success. If
the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that
drop will free the gem object, and the subsequent drm_gem_object_get()
will be a UAF. Fix by grabbing a reference before calling the mmap
helper.

This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):
  "For that to work properly the drm_gem_object_get() call in
  drm_gem_ttm_mmap() must be moved so it happens before calling
  obj->funcs->mmap(), otherwise the gem refcount would go down
  to zero."
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4f8e469a2384dfa4047145b[PII_REDACTED]cbb6dc0; https://git.kernel.org/stable/c/8244a3bc27b3efd057da154b8d7e414670d5044f; https://git.kernel.org/stable/c/4f8e469a2384dfa4047145b[PII_REDACTED]cbb6dc0
CVE: CVE-2021-47201
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

iavf: free q_vectors before queues in iavf_disable_vf

iavf_free_queues() clears adapter->num_active_queues, which
iavf_free_q_vectors() relies on, so swap the order of these two function
calls in iavf_disable_vf(). This resolves a panic encountered when the
interface is disabled and then later brought up again after PF
communication is restored.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c; https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1; https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e
CVE: CVE-2021-47202
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: Fix NULL pointer dereferences in of_thermal_ functions

of_parse_thermal_zones() parses the thermal-zones node and registers a
thermal_zone device for each subnode. However, if a thermal zone is
consuming a thermal sensor and that thermal sensor device hasn't probed
yet, an attempt to set trip_point_*_temp for that thermal zone device
can cause a NULL pointer dereference. Fix it.

 console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp
 ...
 Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
 ...
 Call trace:
  of_thermal_set_trip_temp+0x40/0xc4
  trip_point_temp_store+0xc0/0x1dc
  dev_attr_store+0x38/0x88
  sysfs_kf_write+0x64/0xc0
  kernfs_fop_write_iter+0x108/0x1d0
  vfs_write+0x2f4/0x368
  ksys_write+0x7c/0xec
  __arm64_sys_write+0x20/0x30
  el0_svc_common.llvm[PII_REDACTED]325364641+0xbc/0x1bc
  do_el0_svc+0x28/0xa0
  el0_svc+0x14/0x24
  el0_sync_handler+0x88/0xec
  el0_sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0750f769b95841b34a9fe8c418dd792ff526bf86; https://git.kernel.org/stable/c/6a315471cb6a07f651e1d3adc8962730f4fcccac; https://git.kernel.org/stable/c/828f4c31684da94ecf0b44a2cbd35bbede04f0bd
CVE: CVE-2021-47203
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()

When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
the requests to the adapter. If such an attempt fails, a local "fail_msg"
string is set and a log message output.  The job is then added to a
completions list for cancellation.

Processing of any further jobs from the txq list continues, but since
"fail_msg" remains set, jobs are added to the completions list regardless
of whether a wqe was passed to the adapter.  If successfully added to
txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f; https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5; https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1bace6aa5d
CVE: CVE-2021-47204
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove

Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9; https://git.kernel.org/stable/c/32d[PII_REDACTED]819ddcae58b666c21d2a4ef4c88; https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c
CVE: CVE-2021-47205
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: Unregister clocks/resets when unbinding

Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.

This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.

Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/9bec2b9c[PII_REDACTED]115d2d3374e96f2ccb9b9d; https://git.kernel.org/stable/c/b5dd513daa70ee8f6d281a20bd28485ee9bb7db2; https://git.kernel.org/stable/c/9bec2b9c[PII_REDACTED]115d2d3374e96f2ccb9b9d
CVE: CVE-2021-47206
Published: 2024-04-10
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: host: ohci-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483; https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100; https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460