deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49082
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()

The function mpt3sas_transport_port_remove() called in
_scsih_expander_node_remove() frees the port field of the sas_expander
structure, leading to the following use-after-free splat from KASAN when
the ioc_info() call following that function is executed (e.g. when doing
rmmod of the driver module):

[ 3479.371167] ==================================================================
[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531
[ 3479.393524]
[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436
[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021
[ 3479.409263] Call Trace:
[ 3479.411743]  <TASK>
[ 3479.413875]  dump_stack_lvl+0x45/0x59
[ 3479.417582]  print_address_description.constprop.0+0x1f/0x120
[ 3479.423389]  ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.429469]  kasan_report.cold+0x83/0xdf
[ 3479.433438]  ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.439514]  _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.445411]  ? _raw_spin_unlock_irqrestore+0x2d/0x40
[ 3479.452032]  scsih_remove+0x525/0xc90 [mpt3sas]
[ 3479.458212]  ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]
[ 3479.465529]  ? down_write+0xde/0x150
[ 3479.470746]  ? up_write+0x14d/0x460
[ 3479.475840]  ? kernfs_find_ns+0x137/0x310
[ 3479.481438]  pci_device_remove+0x65/0x110
[ 3479.487013]  __device_release_driver+0x316/0x680
[ 3479.493180]  driver_detach+0x1ec/0x2d0
[ 3479.498499]  bus_remove_driver+0xe7/0x2d0
[ 3479.504081]  pci_unregister_driver+0x26/0x250
[ 3479.510033]  _mpt3sas_exit+0x2b/0x6cf [mpt3sas]
[ 3479.516144]  __x64_sys_delete_module+0x2fd/0x510
[ 3479.522315]  ? free_module+0xaa0/0xaa0
[ 3479.527593]  ? __cond_resched+0x1c/0x90
[ 3479.532951]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 3479.539607]  ? syscall_enter_from_user_mode+0x21/0x70
[ 3479.546161]  ? trace_hardirqs_on+0x1c/0x110
[ 3479.551828]  do_syscall_64+0x35/0x80
[ 3479.556884]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3479.563402] RIP: 0033:0x7f1fc482483b
...
[ 3479.943087] ==================================================================

Fix this by introducing the local variable port_id to store the port ID
value before executing mpt3sas_transport_port_remove(). This local variable
is then used in the call to ioc_info() instead of dereferencing the freed
port structure.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/17d66b1c92bcb41e72271ec60069d3684aaa1c9c; https://git.kernel.org/stable/c/1bb8a7fc64d63ec818e367e1b37676ea2ef2d20c; https://git.kernel.org/stable/c/25c1353dca74ad7cf3fd7ce258fe7c957a147d5e
CVE: CVE-2022-49083
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/omap: Fix regression in probe for NULL pointer dereference

Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started
triggering a NULL pointer dereference for some omap variants:

__iommu_probe_device from probe_iommu_group+0x2c/0x38
probe_iommu_group from bus_for_each_dev+0x74/0xbc
bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
bus_iommu_probe from bus_set_iommu+0x80/0xc8
bus_set_iommu from omap_iommu_init+0x88/0xcc
omap_iommu_init from do_one_initcall+0x44/0x24

This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV)
as noted by Jason Gunthorpe <jgg@ziepe.ca>.

Looks like the regression already happened with an earlier commit
6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs")
that changed the function return type and missed converting one place.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1d89f2b9eadbcf3ce93c6d7238f68299a1f84968; https://git.kernel.org/stable/c/47e239117bd97c8556f9187af7a9a7938db4e021; https://git.kernel.org/stable/c/71ff461c3f41f6465434b9e980c01782763e7ad8
CVE: CVE-2022-49084
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

qede: confirm skb is allocated before using

qede_build_skb() assumes build_skb() always works and goes straight
to skb_reserve(). However, build_skb() can fail under memory pressure.
This results in a kernel panic because the skb to reserve is NULL.

Add a check in case build_skb() failed to allocate and return NULL.

The NULL return is handled correctly in callers to qede_build_skb().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/034a92c6a81048128fc7b18d278d52438a13902a; https://git.kernel.org/stable/c/4e910dbe36508654a896d5735b318c0b88172570; https://git.kernel.org/stable/c/8928239e5e2e460d95b8a0b89f61671625e7ece0
CVE: CVE-2022-49085
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drbd: Fix five use after free bugs in get_initial_state

In get_initial_state, it calls notify_initial_state_done(skb,..) if
cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
the skb will be freed by nlmsg_free(skb).
Then get_initial_state will goto out and the freed skb will be used by
return value skb->len, which is a uaf bug.

What's worse, the same problem goes even further: skb can also be
freed in the notify_*_state_change -> notify_*_state calls below.
Thus 4 additional uaf bugs happened.

My patch lets the problem callee functions: notify_initial_state_done
and notify_*_state_change return an error code if errors happen.
So that the error codes could be propagated and the uaf bugs can be avoid.

v2 reports a compilation warning. This v3 fixed this warning and built
successfully in my local environment with no additional warnings.
v2: https://lore.kernel.org/patchwork/patch/1435218/
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103; https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024; https://git.kernel.org/stable/c/226e993c[PII_REDACTED]1bfcf4b039a8db56aab362
CVE: CVE-2022-49086
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix leak of nested actions

While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.

Currently there are only two such actions: ct() and set().  However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.

For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():

  actions:clone(ct(commit),0)

Non-freed set() action may also leak the 'dst' structure for the
tunnel info including device references.

Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter's
case).  The problem is also hard to mitigate, because the user doesn't
have direct control over the datapath flows generated by OVS.

Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.

New build time assertion should protect us from this problem if new
actions will be added in the future.

Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all
attributes has to be explicitly checked.  sample() and clone() actions
are mixing extra attributes into the user-provided action list.  That
prevents some code generalization too.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1f30fb9166d4f15a1aa19449b9da871fe0ed4796; https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c; https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509
CVE: CVE-2022-49087
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: fix a race in rxrpc_exit_net()

Current code can lead to the following race:

CPU0                                                 CPU1

rxrpc_exit_net()
                                                     rxrpc_peer_keepalive_worker()
                                                       if (rxnet->live)

  rxnet->live = false;
  del_timer_sync(&rxnet->peer_keepalive_timer);

                                                             timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);

  cancel_work_sync(&rxnet->peer_keepalive_work);

rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
leading to use-after-free.

syzbot report was:

ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: ffff[PII_REDACTED]40 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffffffff815ea4ae R11: [PII_REDACTED] R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc[PII_REDACTED]
FS:  [PII_REDACTED](0000) GS:ffff8880b9c00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fe1f2908924 CR3: [PII_REDACTED] CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
 debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
 kfree+0xd6/0x310 mm/slab.c:3809
 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
 ops_free_list net/core/net_namespace.c:174 [inline]
 cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
 process_one_work+0x996/0x1610 kernel/workqueue.c:2289
 worker_thread+0x665/0x1080 kernel/workqueue.c:2436
 kthread+0x2e9/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
 </TASK>
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950; https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad; https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c
CVE: CVE-2022-49088
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe

This node pointer is returned by of_find_compatible_node() with
refcount incremented. Calling of_node_put() to aovid the refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b04bd4f03bba021959ca339314f6739710f0954; https://git.kernel.org/stable/c/45fdd98b[PII_REDACTED]9615ad1bfb760401863b73; https://git.kernel.org/stable/c/46d120f7c163706d6c31ee00baa0be64c4572b78
CVE: CVE-2022-49089
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition

The documentation of the function rvt_error_qp says both r_lock and s_lock
need to be held when calling that function.  It also asserts using lockdep
that both of those locks are held.  However, the commit I referenced in
Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no
longer covered by r_lock.  This results in the lockdep assertion failing
and also possibly in a race condition.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-667
References: https://git.kernel.org/stable/c/43c2d7890ecabe527448a6c391fb2d9a5e6bbfe0; https://git.kernel.org/stable/c/4d809f69695d4e7d1378b3a072fa9aef23123018; https://git.kernel.org/stable/c/57800cc36e55db0547461c49acf5cd84c0f502b0
CVE: CVE-2022-49090
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

arch/arm64: Fix topology initialization for core scheduling

Arm64 systems rely on store_cpu_topology() to call update_siblings_masks()
to transfer the toplogy to the various cpu masks. This needs to be done
before the call to notify_cpu_starting() which tells the scheduler about
each cpu found, otherwise the core scheduling data structures are setup
in a way that does not match the actual topology.

With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1`
for !leaders in:

 notify_cpu_starting()
   cpuhp_invoke_callback_range()
     sched_cpu_starting()
       sched_core_cpu_starting()

which leads to rq->core not being correctly set for !leader-rq's.

Without this change stress-ng (which enables core scheduling in its prctl
tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning
and then a crash (trimmed for legibility):

[ 1853.805168] ------------[ cut here ]------------
[ 1853.809784] task_rq(b)->core != rq->core
[ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4
...
[ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
...
[ 1854.231256] Call trace:
[ 1854.233689]  pick_next_task+0x3dc/0x81c
[ 1854.237512]  __schedule+0x10c/0x4cc
[ 1854.240988]  schedule_idle+0x34/0x54
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5524cbb1bfcdff0cad0aaa9f94e6092002a07259; https://git.kernel.org/stable/c/790c1567582bda8f[PII_REDACTED]e3330a7c6eb278; https://git.kernel.org/stable/c/87f5d66daa5f457449bb95d6b8d18bb7596aa627
CVE: CVE-2022-49091
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/imx: Fix memory leak in imx_pd_connector_get_modes

Avoid leaking the display mode variable if of_get_drm_display_mode
fails.

Addresses-Coverity-ID: 1443943 ("Resource leak")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/31e449302ed00c38d4068443cf[PII_REDACTED]ab28; https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549; https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8
CVE: CVE-2022-49094
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net/tls: fix slab-out-of-bounds bug in decrypt_internal

The memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting in
tls_set_sw_offload(). The return value of crypto_aead_ivsize()
for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes
memory space will trigger slab-out-of-bounds bug as following:

==================================================================
BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]
Read of size 16 at addr ffff888114e84e60 by task tls/10911

Call Trace:
 <TASK>
 dump_stack_lvl+0x34/0x44
 print_report.cold+0x5e/0x5db
 ? decrypt_internal+0x385/0xc40 [tls]
 kasan_report+0xab/0x120
 ? decrypt_internal+0x385/0xc40 [tls]
 kasan_check_range+0xf9/0x1e0
 memcpy+0x20/0x60
 decrypt_internal+0x385/0xc40 [tls]
 ? tls_get_rec+0x2e0/0x2e0 [tls]
 ? process_rx_list+0x1a5/0x420 [tls]
 ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls]
 decrypt_skb_update+0x9d/0x400 [tls]
 tls_sw_recvmsg+0x3c8/0xb50 [tls]

Allocated by task 10911:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x81/0xa0
 tls_set_sw_offload+0x2eb/0xa20 [tls]
 tls_setsockopt+0x68c/0x700 [tls]
 __sys_setsockopt+0xfe/0x1b0

Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_size
when memcpy() iv value in TLS_1_3_VERSION scenario.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2304660ab6c425df64d95301b601424c6a50f28b; https://git.kernel.org/stable/c/29be1816cbab9a0dc[PII_REDACTED]fd10a92753756; https://git.kernel.org/stable/c/2b7d14c105dd8f6412eda5a91e1e[PII_REDACTED]e3
CVE: CVE-2022-49095
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()

The error handling path of the probe releases a resource that is not freed
in the remove function. In some cases, a ioremap() must be undone.

Add the missing iounmap() call in the remove function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/16ed828b872d12ccba8f07bcc446ae89ba662f9c; https://git.kernel.org/stable/c/1e0c01319dedf1e63ec5df37ead048e17afd92ba; https://git.kernel.org/stable/c/34a47f7ddb4fd1cbd12397aa6f7dad1de08b4050
CVE: CVE-2022-49097
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Avoid writeback threads getting stuck in mempool_alloc()

In a low memory situation, allow the NFS writeback code to fail without
getting stuck in infinite loops in mempool_alloc().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/0bae835b63c53f86cdc524f5962e39409585b22c; https://git.kernel.org/stable/c/1b3fa9a3c420c31e77b406ddc28f3a627100516c; https://git.kernel.org/stable/c/a6caeddd68977a1aaaf62fbd1955b41dd5c3c5d3
CVE: CVE-2022-49098
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Fix potential crash on module unload

The vmbus driver relies on the panic notifier infrastructure to perform
some operations when a panic event is detected. Since vmbus can be built
as module, it is required that the driver handles both registering and
unregistering such panic notifier callback.

After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
though, the panic notifier registration is done unconditionally in the module
initialization routine whereas the unregistering procedure is conditionally
guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability
is set.

This patch fixes that by unconditionally unregistering the panic notifier
in the module's exit routine as well.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2133c422a103cf7c7768c37b9ac382e73b691892; https://git.kernel.org/stable/c/3d0078f8bddd58d9bb1ad40bbe929f8633abb276; https://git.kernel.org/stable/c/5ea98d0f5f035c1bcf1517ccec0e024ae35a48b2
CVE: CVE-2022-49099
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Fix initialization of device object in vmbus_device_register()

Initialize the device's dma_{mask,parms} pointers and the device's
dma_mask value before invoking device_register().  Address the
following trace with 5.17-rc7:

[   49.646839] WARNING: CPU: 0 PID: 189 at include/linux/dma-mapping.h:543
	netvsc_probe+0x37a/0x3a0 [hv_netvsc]
[   49.646928] Call Trace:
[   49.646930]  <TASK>
[   49.646935]  vmbus_probe+0x40/0x60 [hv_vmbus]
[   49.646942]  really_probe+0x1ce/0x3b0
[   49.646948]  __driver_probe_device+0x109/0x180
[   49.646952]  driver_probe_device+0x23/0xa0
[   49.646955]  __device_attach_driver+0x76/0xe0
[   49.646958]  ? driver_allows_async_probing+0x50/0x50
[   49.646961]  bus_for_each_drv+0x84/0xd0
[   49.646964]  __device_attach+0xed/0x170
[   49.646967]  device_initial_probe+0x13/0x20
[   49.646970]  bus_probe_device+0x8f/0xa0
[   49.646973]  device_add+0x41a/0x8e0
[   49.646975]  ? hrtimer_init+0x28/0x80
[   49.646981]  device_register+0x1b/0x20
[   49.646983]  vmbus_device_register+0x5e/0xf0 [hv_vmbus]
[   49.646991]  vmbus_add_channel_work+0x12d/0x190 [hv_vmbus]
[   49.646999]  process_one_work+0x21d/0x3f0
[   49.647002]  worker_thread+0x4a/0x3b0
[   49.647005]  ? process_one_work+0x3f0/0x3f0
[   49.647007]  kthread+0xff/0x130
[   49.647011]  ? kthread_complete_and_exit+0x20/0x20
[   49.647015]  ret_from_fork+0x22/0x30
[   49.647020]  </TASK>
[   49.647021] ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-1188
References: https://git.kernel.org/stable/c/2fe4b[PII_REDACTED]175a32f125062df91a5fe3f73; https://git.kernel.org/stable/c/3a5469582c241abca22500f36a9cb8e9331969cf
CVE: CVE-2022-49100
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio_console: eliminate anonymous module_init & module_exit

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 ffffffff832fc78c t init
 ffffffff832fc79e t init
 ffffffff832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0f3d824bd70a1303464d5e93ee3e7afe7832fe89; https://git.kernel.org/stable/c/3504b0a177208eda85bf472bbf7c9aa77d2b8343; https://git.kernel.org/stable/c/3fd5dee7404ce40c79cba468bb[PII_REDACTED]d975
CVE: CVE-2022-49101
Published: 2025-02-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49102
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

habanalabs: fix possible memory leak in MMU DR fini

This patch fixes what seems to be copy paste error.

We will have a memory leak if the host-resident shadow is NULL (which
will likely happen as the DR and HR are not dependent).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/12e49aefda2e04b07604f13e03f40027cbeb0dc6; https://git.kernel.org/stable/c/30058d3a83cfe8c6aacbfe5ab13c01dd0c1799e3; https://git.kernel.org/stable/c/6d421fb7a9eddd8ce0a05641a3db97283fe20699
CVE: CVE-2022-49103
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify()

[You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]

The reference counting issue happens in two error paths in the
function _nfs42_proc_copy_notify(). In both error paths, the function
simply returns the error code and forgets to balance the refcount of
object `ctx`, bumped by get_nfs_open_context() earlier, which may
cause refcount leaks.

Fix it by balancing refcount of the `ctx` object before the function
returns in both error paths.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9b9feec97c1fc7dd9bb69f62c4905cddf1801599; https://git.kernel.org/stable/c/b37f482ba9f0e6382c188e3fccf6c4b2fdc938eb; https://git.kernel.org/stable/c/b7f114edd54326f730a754547e7cfb197b5bc132
CVE: CVE-2022-49104
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: vchiq_core: handle NULL result of find_service_by_handle

In case of an invalid handle the function find_servive_by_handle
returns NULL. So take care of this and avoid a NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/04202f54dd8899e10f56a89c4c1ede0043fa22af; https://git.kernel.org/stable/c/3b424f6586a870b8d657c5e5419465bbe0e7b61f; https://git.kernel.org/stable/c/42f2142a337ee[PII_REDACTED]09fc924580a7e51b2