<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/misc/vmw_vmci/vmci_context.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-07-16T12:23:57Z</updated>
<entry>
<title>vmci: Prevent the dispatching of uninitialized payloads</title>
<updated>2025-07-16T12:23:57Z</updated>
<author>
<name>Lizhi Xu</name>
</author>
<published>2025-07-03T07:53:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8282013b56059c34590ac0245c74ea7ed7642924'/>
<id>urn:sha1:8282013b56059c34590ac0245c74ea7ed7642924</id>
<content type='text'>
The reproducer executes the host's unlocked_ioctl call in two different
tasks. When init_context fails, the struct vmci_event_ctx is not fully
initialized when executing vmci_datagram_dispatch() to send events to all
vm contexts. This affects the datagram taken from the datagram queue of
its context by another task, because the datagram payload is not initialized
according to the size payload_size, which causes the kernel data to leak
to the user space.

Before dispatching the datagram, and before setting the payload content,
explicitly set the payload content to 0 to avoid data leakage caused by
incomplete payload initialization.

To avoid the oob check failure when executing __compiletime_lessthan()
in memset(), directly use the address of the vmci_event_ctx instance ev
to replace ev.msg.hdr, because their addresses are the same.

Fixes: 28d6692cd8fb ("VMCI: context implementation.")
Reported-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95
Tested-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu &lt;lizhi.xu@windriver.com&gt;
Link: https://lore.kernel.org/r/20250703075334.856445-1-lizhi.xu@windriver.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "vmci: Prevent the dispatching of uninitialized payloads"</title>
<updated>2025-07-03T08:30:09Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2025-07-03T08:30:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8f5d9bed6122b8d96508436e5ad2498bb797eb6b'/>
<id>urn:sha1:8f5d9bed6122b8d96508436e5ad2498bb797eb6b</id>
<content type='text'>
This reverts commit bfb4cf9fb97e4063f0aa62e9e398025fb6625031.

While the code "looks" correct, the compiler has no way to know that
doing "fun" pointer math like this really isn't a write off the end of
the structure as there is no hint anywhere that the structure has data
at the end of it.

This causes the following build warning:

In function 'fortify_memset_chk',
    inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3:
include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  480 |                         __write_overflow_field(p_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So revert it for now and it can come back in the future in a "sane" way
that either correctly makes the structure know that there is trailing
data, OR just the payload structure is properly referenced and zeroed
out.

Fixes: bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads")
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Lizhi Xu &lt;lizhi.xu@windriver.com&gt;
Link: https://lore.kernel.org/r/20250703171021.0aee1482@canb.auug.org.au
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vmci: Prevent the dispatching of uninitialized payloads</title>
<updated>2025-07-01T10:18:22Z</updated>
<author>
<name>Lizhi Xu</name>
</author>
<published>2025-06-27T05:52:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bfb4cf9fb97e4063f0aa62e9e398025fb6625031'/>
<id>urn:sha1:bfb4cf9fb97e4063f0aa62e9e398025fb6625031</id>
<content type='text'>
The reproducer executes the host's unlocked_ioctl call in two different
tasks. When init_context fails, the struct vmci_event_ctx is not fully
initialized when executing vmci_datagram_dispatch() to send events to all
vm contexts. This affects the datagram taken from the datagram queue of
its context by another task, because the datagram payload is not initialized
according to the size payload_size, which causes the kernel data to leak
to the user space.

Before dispatching the datagram, and before setting the payload content,
explicitly set the payload content to 0 to avoid data leakage caused by
incomplete payload initialization.

Fixes: 28d6692cd8fb ("VMCI: context implementation.")
Reported-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9b9124ae9b12d5af5d95
Tested-by: syzbot+9b9124ae9b12d5af5d95@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu &lt;lizhi.xu@windriver.com&gt;
Link: https://lore.kernel.org/r/20250627055214.2967129-1-lizhi.xu@windriver.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: Remove unused vmci_ctx functions</title>
<updated>2025-06-24T15:45:35Z</updated>
<author>
<name>Dr. David Alan Gilbert</name>
</author>
<published>2025-06-14T01:03:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5bce7d47d5b5d53388e31de85adb8a8f578e248f'/>
<id>urn:sha1:5bce7d47d5b5d53388e31de85adb8a8f578e248f</id>
<content type='text'>
vmci_ctx_dbell_destroy_all() and vmci_ctx_pending_datagrams()
were added in 2013 by
commit 28d6692cd8fb ("VMCI: context implementation.")

but have remained unused.

Remove them.

Signed-off-by: "Dr. David Alan Gilbert" &lt;linux@treblig.org&gt;
Link: https://lore.kernel.org/r/20250614010344.636076-2-linux@treblig.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: Rename kvfree_rcu() to kvfree_rcu_mightsleep()</title>
<updated>2023-04-05T13:48:03Z</updated>
<author>
<name>Uladzislau Rezki (Sony)</name>
</author>
<published>2023-02-01T15:08:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=09b2286af617bc6f9480404b565393628f86037d'/>
<id>urn:sha1:09b2286af617bc6f9480404b565393628f86037d</id>
<content type='text'>
The kvfree_rcu() macro's single-argument form is deprecated.  Therefore
switch to the new kvfree_rcu_mightsleep() variant. The goal is to
avoid accidental use of the single-argument forms, which can introduce
functionality bugs in atomic contexts and latency bugs in non-atomic
contexts.

Cc: Bryan Tan &lt;bryantan@vmware.com&gt;
Cc: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Reviewed-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Uladzislau Rezki (Sony) &lt;urezki@gmail.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: replace usage of found with dedicated list iterator variable</title>
<updated>2022-04-24T15:24:09Z</updated>
<author>
<name>Jakob Koschel</name>
</author>
<published>2022-03-24T07:31:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f61c5c830ff0c906907a73a4bfddba6a8f91cbcb'/>
<id>urn:sha1:f61c5c830ff0c906907a73a4bfddba6a8f91cbcb</id>
<content type='text'>
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.

To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].

This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/
Signed-off-by: Jakob Koschel &lt;jakobkoschel@gmail.com&gt;
Link: https://lore.kernel.org/r/20220324073151.66305-1-jakobkoschel@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: Switch to kvfree_rcu() API</title>
<updated>2021-12-21T09:25:15Z</updated>
<author>
<name>Uladzislau Rezki (Sony)</name>
</author>
<published>2021-12-15T11:18:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6da3f33770e08348691d90455ef6149e15551854'/>
<id>urn:sha1:6da3f33770e08348691d90455ef6149e15551854</id>
<content type='text'>
Instead of invoking a synchronize_rcu() to free a pointer
after a grace period we can directly make use of new API
that does the same but in more efficient way.

Signed-off-by: Uladzislau Rezki (Sony) &lt;urezki@gmail.com&gt;
Link: https://lore.kernel.org/r/20211215111845.2514-6-urezki@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: return the correct errno code</title>
<updated>2021-06-24T13:47:13Z</updated>
<author>
<name>Junlin Yang</name>
</author>
<published>2021-06-19T11:28:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7487257cea875a2ee0aab088ee1dd92cd77698d4'/>
<id>urn:sha1:7487257cea875a2ee0aab088ee1dd92cd77698d4</id>
<content type='text'>
When kzalloc failed, should return -ENOMEM rather than -EINVAL.

Signed-off-by: Junlin Yang &lt;yangjunlin@yulong.com&gt;
Link: https://lore.kernel.org/r/20210619112854.1720-1-angkery@163.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: vmw_vmci: fix kernel info-leak by initializing dbells in vmci_ctx_get_chkpt_doorbells()</title>
<updated>2020-12-09T18:36:26Z</updated>
<author>
<name>Anant Thazhemadam</name>
</author>
<published>2020-11-22T22:45:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=31dcb6c30a26d32650ce134820f27de3c675a45a'/>
<id>urn:sha1:31dcb6c30a26d32650ce134820f27de3c675a45a</id>
<content type='text'>
A kernel-infoleak was reported by syzbot, which was caused because
dbells was left uninitialized.
Using kzalloc() instead of kmalloc() fixes this issue.

Reported-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
Tested-by: syzbot+a79e17c39564bedf0930@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam &lt;anant.thazhemadam@gmail.com&gt;
Link: https://lore.kernel.org/r/20201122224534.333471-1-anant.thazhemadam@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>VMCI: Fix integer overflow in VMCI handle arrays</title>
<updated>2019-06-21T14:04:05Z</updated>
<author>
<name>Vishnu DASA</name>
</author>
<published>2019-05-24T15:13:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1c2eb5b2853c9f513690ba6b71072d8eb65da16a'/>
<id>urn:sha1:1c2eb5b2853c9f513690ba6b71072d8eb65da16a</id>
<content type='text'>
The VMCI handle array has an integer overflow in
vmci_handle_arr_append_entry when it tries to expand the array. This can be
triggered from a guest, since the doorbell link hypercall doesn't impose a
limit on the number of doorbell handles that a VM can create in the
hypervisor, and these handles are stored in a handle array.

In this change, we introduce a mandatory max capacity for handle
arrays/lists to avoid excessive memory usage.

Signed-off-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Reviewed-by: Adit Ranadive &lt;aditr@vmware.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
