AI_ONLY_REPORT
package: p11-kit-0.26.2-1.el10
------
Summary: Integer overflow in RPC attribute-array length calculation can  
under-allocate nested attribute storage: a crafted nested template count on  
ILP32 builds can wrap the decoded byte length, under-allocate storage, and  
cause a heap out-of-bounds write during second-pass RPC attribute decoding.
Requirements to exploit: Ability to supply crafted RPC messages to a  
`p11-kit` RPC parser running an ILP32 build with 32-bit `CK_ULONG`, and to  
reach nested attribute-array decoding through `CKA_WRAP_TEMPLATE`,  
`CKA_UNWRAP_TEMPLATE`, or `CKA_DERIVE_TEMPLATE`. The parser itself does not  
require user interaction; practical reachability depends on how the RPC  
endpoint is exposed.
Component affected: `p11-kit-0.26.2-1.el10`, `p11-kit/rpc-message.c`,  
nested attribute-array decoding in  
`p11_rpc_message_get_attribute_array_value()` and  
`p11_rpc_message_get_attribute()`.
Version affected: `p11-kit-0.26.2-1.el10` on ILP32 builds with 32-bit  
`CK_ULONG`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.5 (MEDIUM)
AV:L - Exploitation requires local or equivalent access to a reachable  
`p11-kit` RPC channel; remote reachability is not established by the  
available evidence.
AC:L - The triggering condition is a crafted nested attribute array with  
attacker-controlled `count` and `length`; no race or unusual environmental  
precondition is required beyond an ILP32 build.
PR:N - No prior authentication is required by the vulnerable parser  
logic itself once the attacker can deliver RPC input to it.
UI:N - The parser can be triggered without user interaction.
S:U - The corruption occurs within the vulnerable `p11-kit` process.
C:N - The available evidence does not establish confidentiality impact.
I:N - The available evidence does not establish integrity impact beyond  
memory corruption leading to failure.
A:H - A crafted message can cause a heap out-of-bounds write and crash  
the parsing process.
Impact: Moderate. According to Red Hat’s severity ratings, Important  
usually covers flaws that can easily compromise resources or let remote  
users cause denial of service. Here, the demonstrated effect is a  
crash-capable heap overwrite, but the issue is limited to ILP32 builds and  
to deployments where an attacker can reach the relevant RPC parser, so  
Moderate is more appropriate than Important or Critical.
Embargo: no
Reason: The issue is architecture- and deployment-dependent, the  
demonstrated impact is crash/availability rather than clear system  
compromise, and the mitigation/fix is straightforward. Under Red Hat’s  
guidance, this does not appear to require embargo.
Acknowledgement: Aisle Research
Vulnerability Details: Nested attribute-array decoding is used for  
`CKA_WRAP_TEMPLATE`, `CKA_UNWRAP_TEMPLATE`, and `CKA_DERIVE_TEMPLATE`. In  
`p11_rpc_message_get_attribute_array_value()`, `count` comes directly from  
the RPC payload and is multiplied by `sizeof (CK_ATTRIBUTE)` without  
overflow protection. When `value == NULL`, that first pass returns after  
reporting the possibly wrapped size, so it does not validate the nested  
elements. In the message decode path, `p11_rpc_message_get_attribute()`  
allocates from the outer serialized `length`, checks only the wrapped  
`decode_length`, rewinds the offset, and decodes the nested array a second  
time into the smaller buffer.
```c
if (!p11_rpc_buffer_get_uint32 (buffer, offset, &count))
return false;
if (value_length != NULL)
*value_length = count * sizeof (CK_ATTRIBUTE);
if (value == NULL)
return true;
...
saved_offset = *offset;
if (!serializer->decode (NULL, buffer, offset, NULL, &decode_length))
return false;
...
if (attr->pValue != NULL) {
if (length < decode_length)
return false;
*offset = saved_offset;
if (!serializer->decode (msg, buffer, offset, attr->pValue, NULL))
return false;
}
```
On 32-bit builds where `sizeof (CK_ATTRIBUTE) == 12`, choosing `count =  
357913942` (`0x15555556`) makes `count * 12` wrap to `8` in `CK_ULONG`. If  
the outer serialized `length` is also `8`, the code can allocate 8 bytes  
and then write at least one `CK_ATTRIBUTE` entry (12 bytes) during the  
second pass, producing a heap out-of-bounds write before parsing eventually  
fails. The current evidence demonstrates crash-capable memory corruption;  
it does not establish confidentiality, integrity, or code-execution impact.
Steps to reproduce:
1. Build an ILP32 target with AddressSanitizer, for example with `-m32  
-fsanitize=address`.
2. Craft an RPC message containing a valid nested template attribute of  
type `CKA_WRAP_TEMPLATE`, `CKA_UNWRAP_TEMPLATE`, or `CKA_DERIVE_TEMPLATE`,  
with `validity = 1`.
3. Set the outer serialized `length` to `8`.
4. Encode the nested attribute-array header with `count = 357913942`  
(`0x15555556`), or any value for which `count * sizeof (CK_ATTRIBUTE)`  
wraps below the outer `length` on 32-bit `CK_ULONG`.
5. Append one minimal valid nested attribute record so the second decode  
pass begins writing the first `CK_ATTRIBUTE`; a full payload for all  
advertised elements is not required.
6. Feed the message through a normal RPC parse path that reaches  
`p11_rpc_message_get_attribute()`, and observe an AddressSanitizer  
heap-buffer-overflow during the second decode pass.
Mitigation: Until a fix is applied, do not allow untrusted actors to supply  
RPC messages to affected `p11-kit` decoders on ILP32 builds. Where  
feasible, avoid ILP32 builds for deployments that expose this RPC parsing  
path, because the reported overflow depends on 32-bit `CK_ULONG` arithmetic.
Proposed Fix: Reject nested attribute-array counts that overflow `CK_ULONG`  
before calculating the decoded size, and re-check the second decode pass  
against the original outer `length`.
```diff
diff --git a/p11-kit/rpc-message.c b/p11-kit/rpc-message.c
@@
static bool
p11_rpc_message_get_attribute_array_value (p11_rpc_message *msg,
p11_buffer *buffer,
size_t *offset,
void *value,
CK_ULONG *value_length)
{
uint32_t count, i;
CK_ATTRIBUTE *attr = value;
+    CK_ULONG needed;
if (!p11_rpc_buffer_get_uint32 (buffer, offset, &count))
return false;
+    if (count > (CK_ULONG)-1 / sizeof (CK_ATTRIBUTE))
+        return false;
+    needed = (CK_ULONG)count * sizeof (CK_ATTRIBUTE);
if (value_length != NULL)
       *value_length = count * sizeof (CK_ATTRIBUTE);
+        *value_length = needed;


if (value == NULL)
return true;
@@
bool
p11_rpc_message_get_attribute (p11_rpc_message *msg,
p11_buffer *buffer,
size_t *offset,
CK_ATTRIBUTE *attr)
{
@@
if (attr->pValue != NULL) {
+        CK_ULONG decoded_again = 0;
if (length < decode_length)
return false;
*offset = saved_offset;
       if (!serializer->decode (msg, buffer, offset, attr->pValue, NULL))
+        if (!serializer->decode (msg, buffer, offset, attr->pValue,  
&decoded_again))
+            return false;
+        if (decoded_again > length)
              return false;
      }
```


------
This report was generated using AI technology. Always review AI-generated  
content prior to use