| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: keembay - Fix AEAD unregister count in error path
register_aes_algs() registers the AEAD algorithms before registering the
skcipher algorithms. If skcipher registration fails, the function unwinds
the earlier AEAD registration with crypto_engine_unregister_aeads(), but it
passes ARRAY_SIZE(algs), which is the skcipher table size.
Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper
iterates over the same table that was registered. Also clarify the nearby
comment: the crypto registration helpers clean up algorithms registered
within the same call, while this function must still unwind earlier
successful registration steps. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-base: Fix handling of ultra performance key
The commit message of commit 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches")
states that the ultra performance key contains additional data
after the type and code fields. The event data passed to
dell_wmi_process_key() is already parsed, so "buffer" already
starts after those two fields.
Use the correct index for accessing the first data field to avoid
a potential buffer overread. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Validate string descriptors
The string descriptor length includes a two-byte header while the UTF-16
payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code
units, not bytes. Passing the payload byte count can make it read beyond
the descriptor buffer.
Validate that the payload has an even byte count, pass a code-unit count to
the converter, and allocate sufficient UTF-8 output space.
The raw string buffer starts after the descriptor header but its size is
bLength. Copying bLength bytes from that pointer can read beyond the
response buffer.
Allocate a zeroed bLength-sized buffer and copy only the UTF-16
payload. This preserves the raw buffer size consumed by the RPMB device-ID
ABI while avoiding the overread. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event()
There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so
the parse infrastructure does not enforce a minimum length for the event
struct. Additionally, the num_vdevs field is taken directly from firmware
and used as a loop bound over the vdev_ids array without checking that it
fits within the TLV payload. Either condition can cause an out-of-bounds
read.
Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so
the parse infrastructure enforces a minimum length for the fixed-size event
struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload
length of a parsed TLV from the header preceding its data pointer. Use it
in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before
the loop.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()
Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the
mac_phy_caps buffer as tot_phy_id * len, where len is clamped to
min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent
memcpy() destination advances by sizeof(full struct) per slot via C
pointer arithmetic, not by the clamped len. When firmware sends short
TLVs, the second and later slots are written past the end of the
allocation.
The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the
buffer with full-struct pointer arithmetic, so the allocation must match
that stride.
Fix by using kzalloc_objs(), which derives the element size from the
pointer type, making allocation size and pointer stride provably
consistent regardless of what len the firmware provides.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, x86: Fix trampoline stack size for 128-bit arguments
btf_distill_func_proto() accepts a function argument up to 16 bytes, so a
128-bit scalar such as __int128 reaches the x86 trampoline with
arg_size == 16. But the current implementation assumes an __int128
argument only needs one register, so the register save area is
under-allocated and save_args() overwrites adjacent stack slots.
Compute the register count from arg_size for all arguments to fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data()
In that function, we round down the start position and round up the
ending position.
But during the calculation of @len, we use "round_up(start + len,
sectorsize)", which is the rounded up end position, not the rounded up
length.
Which results a much larger length, and later we are still using
"start + len", which is completely incorrect.
Fix it by declaring a local @aligned_start and @aligned_len and use them
instead. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate orphan slot during inode read
Patch series "ocfs2: validate active orphan slots during inode read".
OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes.
A corrupted slot can therefore index osb_orphan_wipes or the slot-local
system-inode cache outside their allocations before the corruption is
reported.
Patch 1 validates the ordinary orphan slot used by inode wipe processing.
Patch 2 validates the append-DIO orphan slot used by DIO completion and
orphan recovery. Both checks reject corrupt metadata at the existing inode
validation boundary.
This patch (of 2):
[BUG]
A corrupted dinode with OCFS2_ORPHANED_FL can carry an
i_orphaned_slot outside the mounted filesystem slot range.
ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking
up the orphan directory, causing an out-of-bounds memory access.
BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102
Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85
Call Trace:
...
ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102
ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840
ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline]
ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295
evict+0x38e/0x8f0 fs/inode.c:810
iput_final fs/inode.c:1914 [inline]
iput fs/inode.c:1966 [inline]
iput+0x55b/0x8b0 fs/inode.c:1926
ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374
ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373
...
[CAUSE]
ocfs2_validate_inode_block() validates i_suballoc_slot but leaves
the active ordinary orphan slot unchecked. Downstream consumers
assume that the value is smaller than osb->max_slots.
[FIX]
Reject an active i_orphaned_slot outside the slot range during
dinode validation, before the inode reaches orphan wipe processing. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user()
ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC
login response with
user->passkey_sz = resp->hash_sz;
user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP);
if (user->passkey)
memcpy(user->passkey, resp->hash, resp->hash_sz);
resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is
only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login
response can set hash_sz well beyond that (up to 65535), so the memcpy()
reads past the end of the response object. ipc_validate_msg() does not
bound hash_sz, so reject any response whose hash_sz exceeds the on-stack
hash[] buffer before allocating and copying.
[ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680
[ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611
[ 2030.242296]
[ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy)
[ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work
[ 2030.242763] Call Trace:
[ 2030.242769] <TASK>
[ 2030.242776] dump_stack_lvl+0xa2/0xd0
[ 2030.242794] print_address_description+0x77/0x200
[ 2030.242815] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242831] print_report+0x58/0x70
[ 2030.242848] kasan_report+0x117/0x150
[ 2030.242869] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242888] kasan_check_range+0x3c7/0x3f0
[ 2030.242908] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242925] __asan_memcpy+0x29/0x70
[ 2030.242942] ksmbd_alloc_user+0x278/0x680
[ 2030.242960] ksmbd_login_user+0xc3/0x120
[ 2030.242978] ntlm_authenticate+0x5e6/0x1b00
[ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10
[ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0
[ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10
[ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140
[ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0
[ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300
[ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10
[ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0
[ 2030.243208] handle_ksmbd_work+0x954/0x1280
[ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10
[ 2030.243249] ? process_scheduled_works+0xa07/0x1490
[ 2030.243270] ? process_scheduled_works+0xa07/0x1490
[ 2030.243291] process_scheduled_works+0xa70/0x1490
[ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10
[ 2030.243340] ? do_raw_spin_lock+0x130/0x300
[ 2030.243358] ? lock_is_held_type+0x7b/0x110
[ 2030.243388] worker_thread+0x932/0xe20
[ 2030.243415] kthread+0x38a/0x470
[ 2030.243431] ? __pfx_worker_thread+0x10/0x10
[ 2030.243451] ? __pfx_kthread+0x10/0x10
[ 2030.243467] ret_from_fork+0x484/0x910
[ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10
[ 2030.243501] ? __switch_to+0xc77/0x12c0
[ 2030.243523] ? __pfx_kthread+0x10/0x10
[ 2030.243540] ret_from_fork_asm+0x1a/0x30
[ 2030.243564] </TASK>
[ 2030.243570]
[ 2030.290164] Allocated by task 19279:
[ 2030.290911] kasan_save_track+0x3e/0x80
[ 2030.292179] __kasan_kmalloc+0x72/0x90
[ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0
[ 2030.294467] handle_generic_event+0x59b/0x750
[ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340
[ 2030.296553] genl_rcv_msg+0x606/0x7b0
[ 2030.297129] netlink_rcv_skb+0x22b/0x4a0
[ 2030.298500] genl_rcv+0x2d/0x40
[ 2030.299273] netlink_unicast+0x7ba/0x930
[ 2030.300019] netlink_sendmsg+0x8c3/0xb00
[ 2030.301073] __sock_sendmsg+0xec/0x140
[ 2030.301579] __sys_sendto+0x357/0x470
[ 2030.302255] __x64_sys_sendto+0xe3/0x100
[ 2030.303425] do_syscall_64+0x135/0x460
[ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2030.305594]
[ 2030.305819] The buggy address belongs to the object at ffff888121bb6640
[ 2030.305819] which belongs to the cache kmalloc-192 of size 192
[ 2030.309595] The buggy address
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size
smb_check_perm_dacl() validates that the DACL fits inside the NT
security descriptor, but then bounds its two ACE walks by the
remaining NTSD length (acl_size) rather than the DACL's declared
size (pdacl_size).
When pdacl->size is smaller than the trailing NTSD buffer, bytes
after the declared DACL boundary - still inside the stored security
descriptor - are parsed as ACEs during access checks. A crafted
DACL can place an access-granting ACE beyond pdacl->size, and the
current code accepts it during SMB2_CREATE access validation, while
parse_dacl() and smb_inherit_dacl() stop at pdacl_size.
Bound both ACE walks by pdacl_size to match the DACL boundary
semantics used elsewhere in the server.
Validation:
- semantic KUnit harness shows the post-boundary ACE is selected
before the fix and rejected (EACCES) after it
- linux master (7.2-rc6), x86_64 |
| In the Linux kernel, the following vulnerability has been resolved:
net: qlcnic: validate unified ROM sections before loading
The unified ROM parser reads directory, product, and data-descriptor fields
from the firmware file. Existing validation forms table and data ends with
unchecked additions and multiplications. Malformed values can wrap before
they are compared with the firmware size. The parser also dereferences
typed pointers at firmware-controlled offsets.
Valid descriptor extents alone are insufficient for the consumers. The
loader reads a fixed-size bootloader regardless of its declared size, the
version parser assumes a 17-byte tail, and a partial final firmware word is
read as a full u64. A truncated image can therefore make the driver read
beyond the firmware allocation during validation or loading.
Replace the pointer-returning parser with bounded range helpers. Validate
table entry sizes, descriptor indices, section ranges, the fixed
bootloader load length, and the version tail before exposing any section.
Read all file fields with unaligned little-endian accessors and assemble a
partial final word from only the bytes that remain. Apply the same range
checks to the legacy image before reading its fixed fields. |
| In the Linux kernel, the following vulnerability has been resolved:
ceph: bound copied dentry name length in NFS export get_name
ceph_get_name() copies the MDS-supplied name into the caller's
NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len)
and then writes name[rinfo->dname_len] = 0, without checking dname_len
against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply
with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies
rde->name / rde->name_len the same unchecked way.
Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name
buffer in a client's NFS-export get_name path, a slab out-of-bounds write
reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.
Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
-ENAMETOOLONG before the copy, and use it in both ceph_get_name() and
__get_snap_name(). |
| In the Linux kernel, the following vulnerability has been resolved:
ceph: bound num_export_targets array for mds info v2/v3
ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from
each per-mds info record and advances the decode cursor by
num_export_targets * sizeof(u32) without first checking that many bytes
remain. The only upper-bound check that catches a runaway cursor
(*p > info_end) is gated on info_v >= 4, because info_end is left NULL
for info_v 2 and 3. When the monitor sends an MDS map whose per-mds
info version is 2 or 3 with an oversized num_export_targets, the cursor
moves past the message front buffer and the later export-targets loop
calls the unchecked ceph_decode_32() on out-of-bounds memory.
A kernel client processes CEPH_MSG_MDS_MAP from its monitor session
(net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to
ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and
calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an
on-path attacker on an unsigned/unencrypted messenger session, can
therefore drive an out-of-bounds read in the client kernel; on x86_64
with KASAN it is reported as a slab-out-of-bounds read in
ceph_mdsmap_decode(). The decoded values land in the internal
info->export_targets[] array, so the consequence is a kernel
out-of-bounds read, not an information leak to the attacker.
Impact: a malicious or compromised Ceph monitor sending an MDS map with
a per-mds info version of 2 or 3 and an oversized num_export_targets
field triggers an out-of-bounds read in the CephFS client kernel.
Add a ceph_decode_need() for the export-targets array before advancing
the cursor, so the bound is enforced for every info_v >= 2, not only
info_v >= 4. This mirrors the count-then-need idiom already used for
m_data_pg_pools later in the same function.
Compute the export-targets byte count with size_mul() and reuse that
checked length when advancing the cursor, so the attacker-controlled
num_export_targets multiplication fails closed on overflow rather than
relying on the later kcalloc() guard. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2()
coalesce_t2() computes data pointers directly from server-supplied
DataOffset fields with no validation against buffer bounds:
data_area_of_tgt = (char *)&pSMBt->hdr.Protocol +
get_unaligned_le16(&pSMBt->t2_rsp.DataOffset);
data_area_of_src = (char *)&pSMBs->hdr.Protocol +
get_unaligned_le16(&pSMBs->t2_rsp.DataOffset);
data_area_of_tgt += total_in_tgt;
...
memcpy(data_area_of_tgt, data_area_of_src, total_in_src);
A small DataOffset can push a pointer below the actual byte area,
overwriting header fields; a large one can push it past the buffer
end, causing out-of-bounds heap reads (source) or writes (target).
The BCC overflow guard does not prevent this: BCC reflects how much
data is present, while DataOffset controls where in the buffer it
starts.
The "validate target area" comment present since the function was
first written in 2005 was a placeholder that was never implemented.
Add lower- and upper-bound checks for both data pointers before the
memcpy, and before any target header fields are modified. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject a tree connect response whose byte count is too small
CIFSTCon() bounds its strnlen() over the byte area with the server's
ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int
and converts to a huge size_t. The later subtraction wraps the __u16
bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of
up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the
slab object, and the bytes reach userspace through tcon->nativeFileSystem
in /proc/fs/cifs/DebugData.
Reject a byte area too small for what the parser consumes. Two bytes is
the least it can consume, and no conformant response carries fewer. The
new trace point is the 129th smb_eio_trace entry, which __mode(byte)
cannot represent, so the attribute goes with it. |
| In the Linux kernel, the following vulnerability has been resolved:
dm array: validate array block headers on read
array_block_check() validates blocknr and csum and nothing else, while
node_check(), next to it, has bounded the structural fields since both
were written. dm_array_cursor_next() takes its loop bound from the
on-disk nr_entries and element_at() is unguarded pointer arithmetic, so
a count larger than the block holds keeps the cursor in one block while
the index grows past it and the read walks off the dm-bufio buffer --
dm_cache_load_mappings() drives it once per cache block at activation.
Check the header against itself: reject a zero value_size, require
max_entries to equal calc_max_entries() for that value_size and block
size, and require nr_entries to fit. Equality rather than an upper bound,
since a count below the real capacity trips BUG_ON() in fill_ablock() and
trim_ablock(). Metadata dm-array writes satisfies all three. |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2
gss_krb5_verify_mic_v2() reads the token ID at ptr[0..1], the flags
byte at ptr[2], and padding at ptr[3..7], then passes
ptr + GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg().
None of these accesses check read_token->len first.
The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus
ctx->krb5e->cksum_len (12-24, depending on the enctype). All callers
accept shorter tokens from the wire:
- gss_unwrap_resp_integ() enforces only an upper bound
(offset + len <= rcv_buf->len) before allocating
mic.data = kmalloc(len) and passing it to gss_verify_mic().
A malicious NFS server can therefore supply a short checksum
opaque, producing a small slab allocation that the Kerberos MIC
verifier reads past.
- gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400)
before passing the wire-supplied length to
gss_validate_seqno_mic(), which constructs a mic xdr_netobj
and calls gss_verify_mic().
- svcauth_gss_verify_header() enforces only
checksum.len >= XDR_UNIT (4 bytes) before dispatching to
gss_verify_mic().
- svcauth_gss_unwrap_integ() checks only that the checksum fits
in gsd->gsd_scratch.
Add a length guard at the top of gss_krb5_verify_mic_v2(), before any
ptr[] access or scatterlist construction. Well-formed MIC tokens from
gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN +
cksum_len bytes, so valid traffic is unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Validate Read chunk positions before reconstruction
The RPC/RDMA Read chunk position field is supplied by the remote
client and stored verbatim in the parsed chunk list.
xdr_count_read_segments() checks only 4-byte alignment; it never
compares the position against the received inline body length.
In the single-chunk path, svc_rdma_read_complete_one() splits the
head and tail kvecs at ch_position. A position past the inline
body underflows the tail length, exposing adjacent slab memory to
the upper XDR decoder.
In the multi-chunk path, svc_rdma_read_multiple_chunks() computes
gap lengths between chunks as unsigned subtractions from
ch_position. Overlapping Read chunks cause these subtractions to
underflow. A final position past the inline body likewise
underflows the trailing gap length. svc_rdma_copy_inline_range()
then copies past the receive buffer into request pages that are
returned to the client through the Reply channel.
Bound inline-range copies in svc_rdma_copy_inline_range() against
the decoded inline RPC body saved in rc_saved_arg. Reject a
single Read chunk positioned beyond that body, and reject
multi-chunk lists where accumulated read bytes exceed the next
chunk's position. Apply the same position and overlap checks in
the call-chunk interleaving path. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate directory-index entry counts when reading metadata
ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and
signature of an indexed-directory block before it reaches higher-level
callers, but neither validator bounds the ocfs2_dx_entry_list counts
against the capacity of the block that holds them.
ocfs2_dx_dir_search() then walks
for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++)
dx_entry = &entry_list->de_entries[i];
over de_num_used entries with no bounds check. entry_list is either
dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root,
dx_root->dr_entries. A crafted on-disk image can set de_num_used (and
de_count, which is the __counted_by_le() bound of de_entries) to 0xffff
and make the walk read far past the end of the 4KB metadata block, giving
a slab out-of-bounds read reachable from any path lookup, stat() or open()
on an indexed directory once the image is mounted.
Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during
block read") already bounds dr_list for the non-inline dx_root, but left
the inline dr_entries path and the dx_leaf dl_list unchecked. Add the
same read-time validation for both entry lists: de_count must equal the
capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and
de_num_used must not exceed de_count, rejecting corrupted metadata with
-EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry
array.
de_count is always written as exactly the block capacity when a leaf or
inline root is formatted, so the equality check does not reject any valid
image.
Found by 0sec automated security-research tooling (https://0sec.ai). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix UVD dpb min size calculation for H264
This should use actual number of references from the decode
message, instead of maximum derived from level.
(cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856) |
