huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49058: kernel: cifs: potential buffer overflow in handling symlinks
Component: kernel
Severity: Moderate
CWE: CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A buffer overflow vulnerability has been identified in the Linux kernel's Common Internet File System (CIFS) module, specifically within the parse_mf_symlink() function. This flaw is caused by insufficient input validation on the link_len value, which dictates the length of a symbolic link. An attacker could exploit this issue by providing an overly large symlink string, leading to a buffer overflow. This can result in memory corruption, system instability, or a denial-of-service condition.


Affected upstream versions: 2.6.37
Fixed upstream versions: 0, 4.14.276, 4.19.239, 4.9.311, 5.10.112, 5.15.35, 5.17.4, 5.18, 5.4.190
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3e582749e742e662a8e9bb37cffac62dccaaa1e2
CVE-2022-49060: kernel: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was found in the smc module in the Linux kernel. A NULL pointer dereference can be triggered due to a missing check before calling the dev_name function, resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.7 and 9.1 via RHSA-2022:7683 [1] and RHSA-2022:8267 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2022:7683

[2]. https://access.redhat.com/errata/RHSA-2022:8267

Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.112, 5.15.35, 5.17.4, 5.18, 5.4.190
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a05f5e26cb8bb4d07e0595545fcad1bb406f0085
CVE-2022-49066: kernel: veth: Ensure eth header is in skb's linear part
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

veth: Ensure eth header is in skb's linear part

After feeding a decapsulated packet to a veth device with act_mirred,
skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),
which expects at least ETH_HLEN byte of linear data (as
__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes
unconditionally).

Use pskb_may_pull() to ensure veth_xmit() respects this constraint.

kernel BUG at include/linux/skbuff.h:2328!
RIP: 0010:eth_type_trans+0xcf/0x140
Call Trace:
 <IRQ>
 __dev_forward_skb2+0xe3/0x160
 veth_xmit+0x6e/0x250 [veth]
 dev_hard_start_xmit+0xc7/0x200
 __dev_queue_xmit+0x47f/0x520
 ? skb_ensure_writable+0x85/0xa0
 ? skb_mpls_pop+0x98/0x1c0
 tcf_mirred_act+0x442/0x47e [act_mirred]
 tcf_action_exec+0x86/0x140
 fl_classify+0x1d8/0x1e0 [cls_flower]
 ? dma_pte_clear_level+0x129/0x1a0
 ? dma_pte_clear_level+0x129/0x1a0
 ? prb_fill_curr_block+0x2f/0xc0
 ? skb_copy_bits+0x11a/0x220
 __tcf_classify+0x58/0x110
 tcf_classify_ingress+0x6b/0x140
 __netif_receive_skb_core.constprop.0+0x47d/0xfd0
 ? __iommu_dma_unmap_swiotlb+0x44/0x90
 __netif_receive_skb_one_core+0x3d/0xa0
 netif_receive_skb+0x116/0x170
 be_process_rx+0x22f/0x330 [be2net]
 be_poll+0x13c/0x370 [be2net]
 __napi_poll+0x2a/0x170
 net_rx_action+0x22f/0x2f0
 __do_softirq+0xca/0x2a8
 __irq_exit_rcu+0xc1/0xe0
 common_interrupt+0x83/0xa0


Affected upstream versions: 2.6.24
Fixed upstream versions: 0, 4.14.276, 4.19.239, 4.9.311, 5.10.112, 5.15.35, 5.17.4, 5.18, 5.4.190
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3de2a02b60a4ef0ab76263216f08c7d095fc7c42
CVE-2022-49072: kernel: gpio: Restrict usage of GPIO chip irq members before initialization
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was found in the GPIO support in the Linux kernel. The GPIO chip IRQ members are exposed before they are completely initialized, potentially causing a NULL pointer dereference, resulting in a system crash and a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

[1]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 5.2.14 < 5.3, 5.3
Fixed upstream versions: 0, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7e88a50704b0c49ad3f2d11e8b963341cf68a89f
CVE-2022-49078: kernel: lz4: fix LZ4_decompress_safe_partial read out of bound
Component: kernel
Severity: Moderate
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

lz4: fix LZ4_decompress_safe_partial read out of bound

When partialDecoding, it is EOF if we've either filled the output buffer
or can't proceed with reading an offset for following match.

In some extreme corner cases when compressed data is suitably corrupted,
UAF will occur.  As reported by KASAN [1], LZ4_decompress_safe_partial
may lead to read out of bound problem during decoding.  lz4 upstream has
fixed it [2] and this issue has been disscussed here [3] before.

current decompression routine was ported from lz4 v1.8.3, bumping
lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd
better fix it first.

[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/


Affected upstream versions: 4.20
Fixed upstream versions: 0, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3
CVE-2022-49080: kernel: mm/mempolicy: fix mpol_new leak in shared_policy_replace
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mm/mempolicy: fix mpol_new leak in shared_policy_replace

If mpol_new is allocated but not used in restart loop, mpol_new will be
freed via mpol_put before returning to the caller.  But refcnt is not
initialized yet, so mpol_put could not do the right things and might
leak the unused mpol_new.  This would happen if mempolicy was updated on
the shared shmem file while the sp->lock has been dropped during the
memory allocation.

This issue could be triggered easily with the below code snippet if
there are many processes doing the below work at the same time:

  shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);
  shm = shmat(shmid, 0, 0);
  loop many times {
    mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);
    mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,
          maxnode, 0);
  }


Affected upstream versions: 3.8
Fixed upstream versions: 0, 4.14.276, 4.19.238, 4.9.311, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8510c2346d9e47a72b7f018a36ef0c39483e53d6
CVE-2022-49081: kernel: highmem: fix checks in __kmap_local_sched_{in,out}
Component: kernel
Severity: Low
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

highmem: fix checks in __kmap_local_sched_{in,out}

When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check
that even slots in the tsk->kmap_ctrl.pteval are unmapped.  The slots are
initialized with 0 value, but the check is done with pte_none.  0 pte
however does not necessarily mean that pte_none will return true.  e.g.
on xtensa it returns false, resulting in the following runtime warnings:

 WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108
 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
 Call Trace:
   dump_stack+0xc/0x40
   __warn+0x8f/0x174
   warn_slowpath_fmt+0x48/0xac
   __kmap_local_sched_out+0x51/0x108
   __schedule+0x71a/0x9c4
   preempt_schedule_irq+0xa0/0xe0
   common_exception_return+0x5c/0x93
   do_wp_page+0x30e/0x330
   handle_mm_fault+0xa70/0xc3c
   do_page_fault+0x1d8/0x3c4
   common_exception+0x7f/0x7f

 WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0
 CPU: 0 PID: 101 Comm: touch Tainted: G        W         5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
 Call Trace:
   dump_stack+0xc/0x40
   __warn+0x8f/0x174
   warn_slowpath_fmt+0x48/0xac
   __kmap_local_sched_in+0x50/0xe0
   finish_task_switch$isra$0+0x1ce/0x2f8
   __schedule+0x86e/0x9c4
   preempt_schedule_irq+0xa0/0xe0
   common_exception_return+0x5c/0x93
   do_wp_page+0x30e/0x330
   handle_mm_fault+0xa70/0xc3c
   do_page_fault+0x1d8/0x3c4
   common_exception+0x7f/0x7f

Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.


Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c21d040de6225414547d9bd31cd200f290991c85
CVE-2022-49086: kernel: net: openvswitch: fix leak of nested actions
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was found in the Open vSwitch module in the Linux kernel. Improper handling of allocated memory can lead to a memory leak, potentially impacting system performance and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.4, 8.7, 9.0 and 9.1 via RHSA-2022:5626 [1], RHSA-2022:7683 [2], RHSA-2022:8973 [3] and RHSA-2022:8267 [4], respectively.

[1]. https://access.redhat.com/errata/RHSA-2022:5626

[2]. https://access.redhat.com/errata/RHSA-2022:7683

[3]. https://access.redhat.com/errata/RHSA-2022:8973

[4]. https://access.redhat.com/errata/RHSA-2022:8267

Affected upstream versions: 4.3
Fixed upstream versions: 0, 4.19.249, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.200
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7438dc55c0709819b813f4778aec2c48b782990b
CVE-2022-49087: kernel: rxrpc: fix a race in rxrpc_exit_net()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
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>


Affected upstream versions: 4.17
Fixed upstream versions: 0, 4.19.238, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 864297ee30727ae6233f80296b7fc91442620b05
CVE-2022-49090: kernel: arch/arm64: Fix topology initialization for core scheduling
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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 0000000000000010
...
[ 1854.231256] Call trace:
[ 1854.233689]  pick_next_task+0x3dc/0x81c
[ 1854.237512]  __schedule+0x10c/0x4cc
[ 1854.240988]  schedule_idle+0x34/0x54


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 87f5d66daa5f457449bb95d6b8d18bb7596aa627
CVE-2022-49097: kernel: NFS: Avoid writeback threads getting stuck in mempool_alloc()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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().


Affected upstream versions: 5.3
Fixed upstream versions: 0, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c74e2f6ecc51bd08bb5b0335477dba954a50592e
CVE-2022-49098: kernel: Drivers: hv: vmbus: Fix potential crash on module unload
Component: kernel
Severity: Low
CWE: CWE-459 (Incomplete Cleanup)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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.


Affected upstream versions: 4.19.118 < 4.19.238, 5.4.35 < 5.4.189, 5.6.7 < 5.7, 5.7
Fixed upstream versions: 0, 4.19.238, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189, 5.7
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6b4c0149a56147b29169e07000d566162892722a
CVE-2022-49107: kernel: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix memory leak in ceph_readdir when note_last_dentry returns error

Reset the last_readdir at the same time, and add a comment explaining
why we don't free last_readdir when dir_emit returns false.


Affected upstream versions: 2.6.34
Fixed upstream versions: 0, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f4429786129648a8f4bb1e5faa143c4478cc5c4a
CVE-2022-49109: kernel: ceph: fix inode reference leakage in ceph_get_snapdir()
Component: kernel
Severity: Moderate
CWE: CWE-459 (Incomplete Cleanup)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix inode reference leakage in ceph_get_snapdir()

The ceph_get_inode() will search for or insert a new inode into the
hash for the given vino, and return a reference to it. If new is
non-NULL, its reference is consumed.

We should release the reference when in error handing cases.


Affected upstream versions: 2.6.34
Fixed upstream versions: 0, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3ae7163598c611a8892698e0c056fe794e52b44b
CVE-2022-49111: kernel: Bluetooth: Fix use after free in hci_send_acl
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's Bluetooth subsystem in the `hci_disconn_phylink_complete_evt()` function. Improper cleanup and reference handling can lead to a connection object, `hcon`, being freed and then later accessed during a subsequent function call. This issue can lead to a use-after-free scenario, leading to system instability, memory corruption, and potential code execution.


Affected upstream versions: 3.8
Fixed upstream versions: 0, 4.14.276, 4.19.238, 4.9.311, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c41de54b0a963e59e4dd04c029a4a6d73f45ef9c
CVE-2022-49114: kernel: scsi: libfc: Fix use after free in fc_exch_abts_resp()
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's SCSI libfc library in the `fc_exch_abts_resp()` function, which can lead to a use-after-free scenario. This issue can occur because the function calls `fc_exch_release()`, which decrements a reference count stored in the `ep` object and then frees the object once the count is zero. However, the `ep` object is referenced again and can result in the now-freed `ep` pointer being accessed, resulting in system instability, memory corruption, and potential arbitrary code execution.


Affected upstream versions: 2.6.29
Fixed upstream versions: 0, 4.14.276, 4.19.238, 4.9.311, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4a131d4ea8b581ac9b01d3a72754db4848be3232
CVE-2022-49116: kernel: Bluetooth: use memset avoid memory leaks
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 5.7 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2025-02-26T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: use memset avoid memory leaks

Use memset to initialize structs to prevent memory leaks
in l2cap_ecred_connect

Statement: The bug is that if L2CAP being used during Bluetooth connection, then data leak could happen. Means that some of the data area not initialized by zeros, so random data could potentially leak as result of l2cap_ecred_connect function usage. The security impact is limited, because this data structure being initialized with some actual data and cases when actually some random bytes leakage could happen limited.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9567d54e70ff58c2695c2cc2e53c86c67551d3e6
CVE-2022-49122: kernel: dm ioctl: prevent potential spectre v1 gadget
Component: kernel
Severity: Moderate
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's `dm-ioctl` interface in the `lookup_ioctl()` function, which accepts a user-provided `cmd` value that is used to index the `_ioctls` array directly. This issue could lead to an out-of-bounds access if the CPU speculatively executes the array access before `cmd` is confirmed as valid, allowing an attacker to exploit a Spectre v1 gadget attack.

Statement: Red Hat has rated this vulnerability with a security impact of Moderate. All Red Hat products are being evaluated for impact and Red Hat will work with the Linux community to analyze and correct any issues found. 

Successful exploitation of this flaw requires the attacker to have advanced knowledge of the software versions used on the system. 

For additional information about this flaw, including possible mitigations, please refer to: https://access.redhat.com/solutions/3545361

Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.14.276, 4.19.238, 4.9.311, 5.10.111, 5.15.34, 5.16.20, 5.17.3, 5.18, 5.4.189
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 76c94651005f58885facf9c973007f5ea01ab01f