huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-53072: kernel: platform/x86/amd/pmc: Detect when STB is not available
Component: kernel
Severity: Low
CWE: CWE-20 (Improper Input Validation)
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: 2024-11-19T00:00:00+00:00

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

platform/x86/amd/pmc: Detect when STB is not available

Loading the amd_pmc module as:

    amd_pmc enable_stb=1

...can result in the following messages in the kernel ring buffer:

    amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff
    ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
    WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340

Further debugging reveals that this occurs when the requests for
S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,
indicating that the STB is inaccessible. To prevent the ioremap
warning and provide clarity to the user, handle the invalid address
and display an error message.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a50863dd1f92d43c975ab2ecc3476617fe98a66e
CVE-2024-53074: kernel: wifi: iwlwifi: mvm: don't leak a link on AP removal
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
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: 2024-11-19T00:00:00+00:00

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

wifi: iwlwifi: mvm: don't leak a link on AP removal

Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.


Affected upstream versions: 6.9
Fixed upstream versions: 0, 6.11.7, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 70ddf9ce1894c48dbbf10b0de51a95e4fb3dd376
CVE-2024-53082: kernel: virtio_net: Add hash_key_length check
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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

virtio_net: Add hash_key_length check

Add hash_key_length check in virtnet_probe() to avoid possible out of
bound errors when setting/reading the hash key.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f3401e3c8d339ddb6ccb2e3d11ad634b7846a806
CVE-2024-53085: kernel: tpm: Lock TPM chip in tpm_pm_suspend() first
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
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: 2024-11-19T00:00:00+00:00

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

tpm: Lock TPM chip in tpm_pm_suspend() first

Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy
according, as this leaves window for tpm_hwrng_read() to be called while
the operation is in progress. The recent bug report gives also evidence of
this behaviour.

Aadress this by locking the TPM chip before checking any chip->flags both
in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED
check inside tpm_get_random() so that it will be always checked only when
the lock is reserved.


Affected upstream versions: 6.1.31 < 6.2, 6.3.5 < 6.4, 6.4
Fixed upstream versions: 0, 6.11.8, 6.12, 6.2, 6.4, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cfaf83501a0cbb104499c5b0892ee5ebde4e967f
CVE-2024-53088: kernel: i40e: fix race condition by adding filter's intermediate sync state
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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

i40e: fix race condition by adding filter's intermediate sync state

Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.

1. Thread T0 allocates a filter in i40e_add_filter() within
        i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
        i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
        refers to the already freed filter memory, causing corruption.

Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
        MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
	please set promiscuous on manually for VF XX".

Exact code for stable reproduction Intel can't open-source now.

The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.


Affected upstream versions: 4.10
Fixed upstream versions: 0, 5.15.172, 6.1.117, 6.11.8, 6.12, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a
CVE-2024-53090: kernel: afs: Fix lock recursion
Component: kernel
Severity: Moderate
CWE: CWE-674 (Uncontrolled Recursion)
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: 2024-11-21T00:00:00+00:00

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

afs: Fix lock recursion

afs_wake_up_async_call() can incur lock recursion.  The problem is that it
is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to
take a ref on the afs_call struct in order to pass it to a work queue - but
if the afs_call is already queued, we then have an extraneous ref that must
be put... calling afs_put_call() may call back down into AF_RXRPC through
rxrpc_kernel_shutdown_call(), however, which might try taking the
->notify_lock again.

This case isn't very common, however, so defer it to a workqueue.  The oops
looks something like:

  BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646
   lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0
  CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351
  Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x47/0x70
   do_raw_spin_lock+0x3c/0x90
   rxrpc_kernel_shutdown_call+0x83/0xb0
   afs_put_call+0xd7/0x180
   rxrpc_notify_socket+0xa0/0x190
   rxrpc_input_split_jumbo+0x198/0x1d0
   rxrpc_input_data+0x14b/0x1e0
   ? rxrpc_input_call_packet+0xc2/0x1f0
   rxrpc_input_call_event+0xad/0x6b0
   rxrpc_input_packet_on_conn+0x1e1/0x210
   rxrpc_input_packet+0x3f2/0x4d0
   rxrpc_io_thread+0x243/0x410
   ? __pfx_rxrpc_io_thread+0x10/0x10
   kthread+0xcf/0xe0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x24/0x40
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   </TASK>


Affected upstream versions: 4.15
Fixed upstream versions: 0, 6.11.9, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d7cbf81df996b1eae2dee8deb6df08e2eba78661
CVE-2024-53091: kernel: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx
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: 2024-11-21T00:00:00+00:00

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

bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx

As the introduction of the support for vsock and unix sockets in sockmap,
tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.
vsock and af_unix sockets have vsock_sock and unix_sock instead of
inet_connection_sock. For these sockets, tls_get_ctx may return an invalid
pointer and cause page fault in function tls_sw_ctx_rx.

BUG: unable to handle page fault for address: 0000000000040030
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:sk_psock_strp_data_ready+0x23/0x60
Call Trace:
 ? __die+0x81/0xc3
 ? no_context+0x194/0x350
 ? do_page_fault+0x30/0x110
 ? async_page_fault+0x3e/0x50
 ? sk_psock_strp_data_ready+0x23/0x60
 virtio_transport_recv_pkt+0x750/0x800
 ? update_load_avg+0x7e/0x620
 vsock_loopback_work+0xd0/0x100
 process_one_work+0x1a7/0x360
 worker_thread+0x30/0x390
 ? create_worker+0x1a0/0x1a0
 kthread+0x112/0x130
 ? __kthread_cancel_work+0x40/0x40
 ret_from_fork+0x1f/0x40

v2:
  - Add IS_ICSK check
v3:
  - Update the commits in Fixes


Affected upstream versions: 5.15
Fixed upstream versions: 0, 6.11.9, 6.12, 6.6.62
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a078a480ff3f43d74d8a024ae10c3c7daf6db149
CVE-2024-53093: kernel: nvme-multipath: defer partition scanning
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
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: 2024-11-21T00:00:00+00:00

A flaw was found in the NVMe multipath support in the Linux kernel. A deadlock can be triggered when an error occurs in the partition scan within the controller's scan_work context, potentially resulting in a denial of service.


Affected upstream versions: 4.15
Fixed upstream versions: 0, 6.1.118, 6.11.9, 6.12, 6.6.62
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 60de2e03f984cfbcdc12fa552f95087c35a05a98
CVE-2024-53096: kernel: mm: resolve faulty mmap_region() error path behaviour
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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: 2024-11-25T00:00:00+00:00

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

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like
control flow and numerous means by which issues can arise and incomplete
state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late
in the process of mapping a VMA, which forms the basis of recently
observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of
checks earlier in the code, simplifying things by moving the core of the
logic into a static internal function __mmap_region().

Doing this allows us to perform a number of checks up front before we do
any real work, and allows us to unwind the writable unmap check
unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed
   memory hook, allowing us to exit early and avoid having to perform
   complicated and error-prone close/free logic. We carefully free
   iterator state on both success and error paths.

2. The enclosing mmap_region() function handles the mapping_map_writable()
   logic early. Previously the logic had the mapping_map_writable() at the
   point of mapping a newly allocated file-backed VMA, and a matching
   mapping_unmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable
   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
   doing so does not invalidate the seal check we just performed, and we in
   any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the
   opposite.

3. We also move arch_validate_flags() up into the mmap_region()
   function. This is only relevant on arm64 and sparc64, and the check is
   only meaningful for SPARC with ADI enabled. We explicitly add a warning
   for this arch if a driver invalidates this check, though the code ought
   eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close
the VMA on error paths, as we place all checks which might fail prior to a
call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason
about and more robust.


Affected upstream versions: 5.10.150 < 5.10.231, 5.15.75 < 5.15.174, 5.19.17 < 5.20, 6.0.3 < 6.1, 6.1
Fixed upstream versions: 0, 5.10.231, 5.15.174, 5.20, 6.1, 6.1.119, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 43323a4e5b3f8ccc08e2f835abfdc7ee9da8f6ed
CVE-2024-53097: kernel: mm: krealloc: Fix MTE false alarm in __do_krealloc
Component: kernel
Severity: Low
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
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: 2024-11-25T00:00:00+00:00

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

mm: krealloc: Fix MTE false alarm in __do_krealloc

This patch addresses an issue introduced by commit 1a83a716ec233 ("mm:
krealloc: consider spare memory for __GFP_ZERO") which causes MTE
(Memory Tagging Extension) to falsely report a slab-out-of-bounds error.

The problem occurs when zeroing out spare memory in __do_krealloc. The
original code only considered software-based KASAN and did not account
for MTE. It does not reset the KASAN tag before calling memset, leading
to a mismatch between the pointer tag and the memory tag, resulting
in a false positive.

Example of the error:
==================================================================
swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188
swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1
swapper/0: Pointer tag: [f4], memory tag: [fe]
swapper/0:
swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.
swapper/0: Hardware name: MT6991(ENG) (DT)
swapper/0: Call trace:
swapper/0:  dump_backtrace+0xfc/0x17c
swapper/0:  show_stack+0x18/0x28
swapper/0:  dump_stack_lvl+0x40/0xa0
swapper/0:  print_report+0x1b8/0x71c
swapper/0:  kasan_report+0xec/0x14c
swapper/0:  __do_kernel_fault+0x60/0x29c
swapper/0:  do_bad_area+0x30/0xdc
swapper/0:  do_tag_check_fault+0x20/0x34
swapper/0:  do_mem_abort+0x58/0x104
swapper/0:  el1_abort+0x3c/0x5c
swapper/0:  el1h_64_sync_handler+0x80/0xcc
swapper/0:  el1h_64_sync+0x68/0x6c
swapper/0:  __memset+0x84/0x188
swapper/0:  btf_populate_kfunc_set+0x280/0x3d8
swapper/0:  __register_btf_kfunc_id_set+0x43c/0x468
swapper/0:  register_btf_kfunc_id_set+0x48/0x60
swapper/0:  register_nf_nat_bpf+0x1c/0x40
swapper/0:  nf_nat_init+0xc0/0x128
swapper/0:  do_one_initcall+0x184/0x464
swapper/0:  do_initcall_level+0xdc/0x1b0
swapper/0:  do_initcalls+0x70/0xc0
swapper/0:  do_basic_setup+0x1c/0x28
swapper/0:  kernel_init_freeable+0x144/0x1b8
swapper/0:  kernel_init+0x20/0x1a8
swapper/0:  ret_from_fork+0x10/0x20
==================================================================


Affected upstream versions: 6.10.14 < 6.11, 5.10.227 < 5.10.230, 5.15.168 < 5.15.173, 6.1.113 < 6.1.118, 6.6.55 < 6.6.62, 6.11.3 < 6.11.9
Fixed upstream versions: 5.10.230, 5.15.173, 6.1.118, 6.11, 6.11.9, 6.6.62
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8ebee7565effdeae6085458f8f8463363120a871
CVE-2024-53103: kernel: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:H)
Public date: 2024-12-02T00:00:00+00:00

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

hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer

When hvs is released, there is a possibility that vsk->trans may not
be initialized to NULL, which could lead to a dangling pointer.
This issue is resolved by initializing vsk->trans to NULL.

Statement: This issue is considered to be a moderate impact flaw, as the exploitation in this will not cause an Intigrity (I:L) threat with the available usecase.

Affected upstream versions: 4.14
Fixed upstream versions: 0, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12.1, 6.13, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 285266ef92f7b4bf7d26e1e95e215ce6a6badb4a
CVE-2024-53104: kernel: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format
Component: kernel
Severity: Important
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H)
Public date: 2024-12-02T00:00:00+00:00

A vulnerability was found in the Linux kernel's USB Video Class driver. A buffer for video frame data is allocated, which does not account for all of the frame formats contained in a video stream, leading to an out-of-bounds write when a stream includes frames with an undefined format. An attacker who is able to influence the format of video streams captured by a system's USB video device could exploit this flaw to alter system memory and potentially escalate their privileges or execute arbitrary code.

Statement: This vulnerability exists in functionality used by the USB Video Class driver to decode the format of video frames. This driver is used for USB devices which capture streaming video, such as webcams. A function which reads streaming video frame metadata does not correctly account for frames in an unknown format, which might cause a buffer allocated for frame data to be undersized.
An attacker must be able to control the frame data captured by a UVC device. This might be accomplished by creating a physical or virtual device with that purpose in mind. An attacker could also modify an existing USB device toward this end.
Because an attacker has some control over what data is written out of bounds, but not strict control over where in the kernel's memory space that data is written, we assess that the impact to confidentiality of this flaw is Low. This vulnerability could be used to escalate privileges if combined with other flaws or other means to predict the kernel's memory layout. By itself, this vulnerability can have negative impacts on both system availability and integrity, as an attacker can overwrite other kernel data structures.

Affected upstream versions: 2.6.26
Fixed upstream versions: 0, 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.12.1, 6.13, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 95edf13a48e75dc2cc5b0bc57bf90d6948a22fe8
CVE-2024-53110: kernel: vp_vdpa: fix id_table array not null terminated error
Component: kernel
Severity: Moderate
CWE: CWE-170 (Improper Null Termination)
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: 2024-12-02T00:00:00+00:00

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

vp_vdpa: fix id_table array not null terminated error

Allocate one extra virtio_device_id as null terminator, otherwise
vdpa_mgmtdev_get_classes() may iterate multiple times and visit
undefined memory.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 870d68fe17b5d9032049dcad98b5781a344a8657
CVE-2024-53113: kernel: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
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: 2024-12-02T00:00:00+00:00

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

mm: fix NULL pointer dereference in alloc_pages_bulk_noprof

We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in
alloc_pages_bulk_noprof() when the task is migrated between cpusets.

When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be
&current->mems_allowed.  when first_zones_zonelist() is called to find
preferred_zoneref, the ac->nodemask may be modified concurrently if the
task is migrated between different cpusets.  Assuming we have 2 NUMA Node,
when traversing Node1 in ac->zonelist, the nodemask is 2, and when
traversing Node2 in ac->zonelist, the nodemask is 1.  As a result, the
ac->preferred_zoneref points to NULL zone.

In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a
allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading
to NULL pointer dereference.

__alloc_pages_noprof() fixes this issue by checking NULL pointer in commit
ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and
commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc
fastpath").

To fix it, check NULL pointer for preferred_zoneref->zone.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.174, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 903d896448c2e50e8652aaba529a30d4d1eaa0e5
CVE-2024-53117: kernel: virtio/vsock: Improve MSG_ZEROCOPY error handling
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
Public date: 2024-12-02T00:00:00+00:00

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

virtio/vsock: Improve MSG_ZEROCOPY error handling

Add a missing kfree_skb() to prevent memory leaks.


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.11.10, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 50061d7319e21165d04e3024354c1b43b6137821
CVE-2024-53118: kernel: vsock: Fix sk_error_queue memory leak
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
Public date: 2024-12-02T00:00:00+00:00

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

vsock: Fix sk_error_queue memory leak

Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.

unreferenced object 0xffff8881028beb00 (size 224):
  comm "vsock_test", pid 1218, jiffies 4294694897
  hex dump (first 32 bytes):
    90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff  ..!.......!.....
    00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff  ..........!.....
  backtrace (crc 6c7031ca):
    [<ffffffff81418ef7>] kmem_cache_alloc_node_noprof+0x2f7/0x370
    [<ffffffff81d35882>] __alloc_skb+0x132/0x180
    [<ffffffff81d2d32b>] sock_omalloc+0x4b/0x80
    [<ffffffff81d3a8ae>] msg_zerocopy_realloc+0x9e/0x240
    [<ffffffff81fe5cb2>] virtio_transport_send_pkt_info+0x412/0x4c0
    [<ffffffff81fe6183>] virtio_transport_stream_enqueue+0x43/0x50
    [<ffffffff81fe0813>] vsock_connectible_sendmsg+0x373/0x450
    [<ffffffff81d233d5>] ____sys_sendmsg+0x365/0x3a0
    [<ffffffff81d246f4>] ___sys_sendmsg+0x84/0xd0
    [<ffffffff81d26f47>] __sys_sendmsg+0x47/0x80
    [<ffffffff820d3df3>] do_syscall_64+0x93/0x180
    [<ffffffff8220012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.11.10, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bea4779a45f49275b1e1b1bd9de03cd3727244d8