In the Linux kernel, the following vulnerability has been resolved:
net: hinic: fix mailbox segment buffer overflow
check_mbox_seq_id_and_seg_len() validates that seq_id does not
exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed
MBOX_SEG_LEN (48). However, this allows the last segment
(seq_id=42) to carry a full 48-byte payload, writing to offset
42*48=2016 for 48 bytes (ending at byte 2064). The receive
buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a
16-byte heap buffer overflow.
The hinic3 driver already handles this correctly by defining
MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it
exceeds the remaining buffer space. Apply the same fix to the
hinic driver.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 8.8
AV:L - The malformed input is a mailbox header (SEQID/SEG_LEN) and 48-byte body that a VF driver writes into its own mailbox registers. The hardware delivers it to the PF's hinic_mbox_func_aeqe_handler() -> recv_mbox_handler(). The attacker is code running in a guest that owns an SR-IOV VF (or a local driver), not a remote network peer, so this is local access.
AC:L - The attacker sends segments seq_id 0..42 in order, each with seg_len=48. check_mbox_seq_id_and_seg_len() accepts all of them, and the memcpy at offset 42*48 overflows every time. The only setup is a VF assigned to the attacker's VM, which is the standard SR-IOV passthrough deployment. Nothing depends on timing or state outside the attacker's control.
PR:L - Writing raw mailbox headers needs kernel control of the VF, i.e. root inside the guest. A VM tenant always has that, and it gives no privilege on the host whose PF driver is corrupted. The random id checked by check_vf_mbox_random_id() is given to every genuine VF, so it does not stop a hostile VF driver.
UI:N - The PF host processes the mailbox message on its own from the AEQ handler. Nobody on the host has to do anything.
S:C - The bug is in a guest-controlled VF's messages, but the overflow corrupts the host kernel heap in the PF driver (recv_mbox->mbox, kzalloc(2048)). That crosses the guest-to-host boundary, like a VM escape.
C:H - Overwriting the first 16 bytes of the neighbouring kmalloc-2048 object with attacker-chosen data can corrupt pointers or length fields in that object. That is a normal route to reading arbitrary host kernel memory.
I:H - recv_mbox_handler() copies 16 attacker-chosen bytes from the mailbox body past the end of the 2048-byte receive buffer. This is a controlled heap out-of-bounds write in the host kernel, which can lead to control-flow hijack.
A:H - The guest can repeat the corruption of the neighbouring host heap object at will, crashing or panicking the host kernel. That takes down every tenant on the host.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The malformed input is a mailbox header (SEQID/SEG_LEN) and 48-byte body that a VF driver writes into its own mailbox registers. The hardware delivers it to the PF's hinic_mbox_func_aeqe_handler() -> recv_mbox_handler(). The attacker is code running in a guest that owns an SR-IOV VF (or a local driver), not a remote network peer, so this is local access.
AC:L - The attacker sends segments seq_id 0..42 in order, each with seg_len=48. check_mbox_seq_id_and_seg_len() accepts all of them, and the memcpy at offset 42*48 overflows every time. The only setup is a VF assigned to the attacker's VM, which is the standard SR-IOV passthrough deployment. Nothing depends on timing or state outside the attacker's control.
PR:L - Writing raw mailbox headers needs kernel control of the VF, i.e. root inside the guest. A VM tenant always has that, and it gives no privilege on the host whose PF driver is corrupted. The random id checked by check_vf_mbox_random_id() is given to every genuine VF, so it does not stop a hostile VF driver.
UI:N - The PF host processes the mailbox message on its own from the AEQ handler. Nobody on the host has to do anything.
S:C - The bug is in a guest-controlled VF's messages, but the overflow corrupts the host kernel heap in the PF driver (recv_mbox->mbox, kzalloc(2048)). That crosses the guest-to-host boundary, like a VM escape.
C:H - Overwriting the first 16 bytes of the neighbouring kmalloc-2048 object with attacker-chosen data can corrupt pointers or length fields in that object. That is a normal route to reading arbitrary host kernel memory.
I:H - recv_mbox_handler() copies 16 attacker-chosen bytes from the mailbox body past the end of the 2048-byte receive buffer. This is a controlled heap out-of-bounds write in the host kernel, which can lead to control-flow hijack.
A:H - The guest can repeat the corruption of the neighbouring host heap object at will, crashing or panicking the host kernel. That takes down every tenant on the host.
CVSS 3.1