| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix integer overflow in verify_tags() bounds check
verify_tags() validates the tagset table unpacked from a policy blob.
For each set it reads a count and checks that advancing the index by
that count stays inside sets.table[]:
u32 cnt = tags->sets.table[i];
if (i+cnt >= tags->sets.size) {
i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32.
sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so
every entry is a raw unbounded 32-bit word taken from the policy blob,
and verify_tags() is the function that is supposed to validate it. A
count close to U32_MAX makes the sum wrap to a small value, the guard
passes, and the inner loop then walks sets.table[++i] past the end of
the kcalloc(size, sizeof(u32)) allocation.
Note that sets.size is bounded by 65535, because unpack_tagsets() reads
it with aa_unpack_array() as a u16, so the wrap cannot be reached by
growing the table; it is reached purely through the attacker-supplied
count.
With sets.size = 2 and sets.table = { 0, 0xffffffff }:
i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run
i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is
false, so the guard is bypassed and the inner loop reads
sets.table[2] -- one element past a two element allocation
The walk continues until an out-of-bounds value happens to be >=
hdrs.size or the access faults, so a crafted policy yields an
out-of-bounds read on the policy load path
(aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags ->
verify_tags). unpack_tags() runs before the perms and DFA tables are
unpacked, so no other table needs to be well formed to reach it.
Policy load is gated by aa_may_manage_policy(), which checks
CAP_MAC_ADMIN relative to the subject's own user namespace rather than
the init user namespace, so with the default
unprivileged_userns_apparmor_policy=1 the path is reachable from an
unprivileged task in a matched-level nested namespace, not only by a
globally privileged one.
Perform the addition in u64 so that it cannot wrap, restoring the
intended i + cnt < sets.size guarantee. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Restore locking around msi_page_list
Unlike a group's default domain, which is always freshly allocated
and privately owned (iommu_group_alloc_default_domain()), VFIO type1's
legacy container merges any newly attached group into an existing
domain whenever their iommu_ops and cache-coherency enforcement match.
iommu_dma_get_msi_page() only asserts the caller's own group mutex is
held (iommu_group_mutex_assert()). On an IOMMU that publishes
IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned
through the legacy container can have their guest drivers probe and
allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands
on a different device fd and group mutex, but both devices' domains
are the same merged domain, so both can enter
iommu_dma_get_msi_page() concurrently and corrupt msi_page_list.
commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a
generic operation") dropped the prior msi_prepare_lock on the
reasoning that "each iommu_domain is unique to a group," which holds
for default domains but not this VFIO type1 case. Restore the static
lock, since it's only guarding a corner case and will likely never
be contended.
iommufd avoids the equivalent problem by having its own callers
(iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever
reaching the shared list. VFIO type1 can't mirror that since it
dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down copied context entry
copied_context_tear_down() zeroes the 128-bit context entry with
context_clear_entry() while the Present bit is still set, and only then
issues the context-cache and IOTLB invalidations. This leaves a window
in which hardware can fetch a torn entry, with some fields already zeroed
while Present is still set, leading to unpredictable behaviour or
spurious faults. While x86 provides strong write ordering, the compiler
may reorder the writes to the two 64-bit halves of the entry, and the
hardware fetch is not guaranteed to be atomic with respect to multiple
CPU writes.
There is no cacheline flush before the invalidation either, so on an
IOMMU without coherent access to the context table the zeroed entry may
not be visible to hardware at the point the invalidation is submitted.
Apply the same ownership handshake described in the VT-d spec, Section
6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present
bit, flush it out to the IOMMU, perform the invalidations, and only then
zero the remainder of the entry. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Tear down scalable-mode context on probe failure
intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via
pci_for_each_dma_alias() and programs a scalable-mode context entry for
each RID. For a device with a dma_alias_mask, the callback is invoked
once for the device’s own RID and once for each alias bit, all with the
same pci_dev, so device_pasid_table_setup() runs for multiple RIDs.
pci_for_each_dma_alias() stops at the first callback error. Therefore, a
failure partway through the walk can leave context entries for already
processed RIDs present and still pointing to the device’s PASID table.
On this error path, intel_iommu_probe_device() currently jumps directly
to intel_pasid_free_table(), which frees the PASID table without
first tearing down those context entries. The IOMMU may then walk a
present context entry whose PASID table pointer references freed
memory.
intel_iommu_release_device() already performs teardown before freeing the
table. Apply the same ordering on the probe failure path.
device_pasid_table_teardown() safely handles RIDs that were never
programmed: iommu_context_addr() returns NULL when no context table has
been allocated, and clearing the Present bit of an already non-present
entry is a no-op. So unwind is safe for both the alias that failed and
any aliases not yet reached. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Flush context cache with correct SID when tearing down aliases
domain_context_clear_one() and device_pasid_table_teardown() are both
invoked once per DMA alias of a device. Each function locates the context
entry using the bus/devfn pair provided by the pci_for_each_dma_alias()
callback, then calls intel_context_flush_no_pasid(), which constructs a
device-selective context-cache invalidation from info->bus and
info->devfn (that is, always the requester ID of the device itself).
As a result, for every alias other than the device’s own RID, the context
entry that was just cleared in memory is never invalidated in the context
cache. Hardware may continue using that stale cached entry. In the
scalable-mode teardown path, intel_pasid_free_table() can then free the
PASID directory still referenced by that stale entry, allowing the IOMMU
to walk freed memory.
Fix this by passing the source ID of the entry being torn down to
intel_context_flush_no_pasid(), instead of deriving it from @info. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: move custom expectation support to helper
Originally, the ct expectation support called nf_ct_helper_ext_add() for
confirmed conntracks, which is invalid, triggering a splat. This was
fixed by commit 1710eb913bdc ("netfilter: nft_ct: skip expectations for
confirmed conntrack") which restricted it to unconfirmed conntracks.
However, early insertion of expectations into the expectations list when
the conntrack is unconfirmed leads to stale entries pointing to the
wrong hlist_head through .pprev due to ct extension reallocation.
Commit 7c9664351980 ("netfilter: move nat hlist_head to nf_conn") moved
the nat hlist_head to nf_conn for this reason:
1. ...
2. When reallocation of extension area occurs we need to fixup the
bysource hash head via hlist_replace_rcu.
I'd rather not increase the size of the struct nf_conn for this feature
has very limited scope: only one expectation can be created at a time
given expect_clash() will make nf_ct_expect_related() reports EBUSY.
For this reason, relax nf_ct_expect_related() not to drop packets in
case expectation creation fails, therefore, expectation creation becomes
best effort.
To address this issue, add an internal ct helper and attach it to the
conntrack entry to streamline the custom ct expectation support with
existing ct helpers.
Expose a new nf_conntrack_helper_release() function to release the
internal helper that is allocated and attached to the conntrack entry to
create the custom expectations. The nft_ct module removal always waits
for rcu grace period, then the NULL helper callback is observed after
this.
This patch also restricts the creation of expectations to different
helpers other than this custom helper that is created for this type of
expectations. |
| IBM MQ could allow an authenticated attacker to cause a denial of service or potentially execute arbitrary code due to improper validation of message distribution list structures. |
| IBM Common Licensing Agent 9.0, Agent 9.0.0.1, Agent 9.0.0.2, ART 9.0, ART 9.0.0.1, and ART 9.0.0.2 is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated attacker to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. |
| IBM Common Licensing Agent 9.0, Agent 9.0.0.1, Agent 9.0.0.2, ART 9.0, ART 9.0.0.1, and ART 9.0.0.2 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. |
| IBM MQ Console allows authenticated non-administrative users to create and start queue managers due to improper authorization checks. |
| IBM Controller 11.0.0 through 11.0.1 FP7, and 11.1.0 through 11.1.3 FP1 could allow an authenticated user to bypass input validation due to improper validation of client-side input of file size. |
| IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 006 could allow an authenticated user to obtain sensitive information from backup files due to incorrect permissions assignment. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length
pair derived from skb->len, without bounding reads to the actual skb
data. Three problems followed:
- For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed.
- The per-TLV header (type, length) was read without checking that two
bytes remained.
- A declared TLV length could run past the end of the buffer, and an
SDREQ with length == 0 made "service_name_len = length - 1" underflow
(size_t), driving an out-of-bounds read in the following strncmp() /
nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3]
without a length check.
A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.
Walk the TLV list by pointer, bounded by skb_tail_pointer() over the
linear skb data, and validate each TLV declared length before use. Add
explicit length checks for SDREQ (>= 1) and SDRES (exactly 2).
Found by 0sec automated security-research tooling (https://0sec.ai). |
| 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:
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
In mi_enum_attr(), the start/end VCN validation for non-resident
attributes is:
if (svcn > evcn + 1) goto out;
When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn
passes the check. For evcn values close to U64_MAX (but not equal to it)
the right-hand side is still a meaningless near-wrap upper bound, so a
malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass
mi_enum_attr() unrejected.
VCN (virtual cluster number) is a cluster index, so any valid evcn is
bounded by the volume's total cluster count, which ntfs3 holds in
sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller
of mi_enum_attr() runs). Reject evcn values that fall outside this range.
However, an empty non-resident attribute (no allocated clusters) is
legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via
attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel
must keep passing, so exclude evcn == U64_MAX from the range check. The
existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is
false) and continues to require svcn == 0 for it, while the range check
rejects every other out-of-range evcn and thereby also defuses the
"evcn + 1" wraparound.
svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1"
implies svcn <= nbits.
[almaz.alexandrovich@paragon-software.com: fixed evcn check] |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: riscv-sbi-mpxy: validate RPMI notification lengths
The SBI return value controls how many bytes are copied from shared
memory into the RPMI notification buffer. It is not validated against
the negotiated shared-memory size before that copy. The event walker
also uses a reversed loop condition and can inspect a short event record.
Validate the complete notification length before copying it, iterate only
while a full event header remains, and stop when a declared event payload
extends beyond the copied notification data. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Do not skip lock checks for single-byte ranges
check_lock_range() uses inclusive ranges. Its callers pass the end
offset as start + length - 1, so start == end represents a valid
single-byte range rather than an empty range.
The start == end shortcut therefore skips mandatory byte-range lock
checks for one-byte reads, writes, copychunk operations and one-byte
truncate ranges. A conflicting lock covering that byte is not checked
and the operation is allowed to proceed.
Remove the shortcut. The truncate size == inode->i_size case is already
handled by only calling check_lock_range() when the new size differs
from the current file size. |
| 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:
smb: smbdirect: free completion queues with ib_free_cq()
smbdirect_connection_destroy_qp() creates the send and receive completion
queues with ib_alloc_cq_any(), which for IB_POLL_WORKQUEUE arms an
internal completion handler that runs ib_cq_poll_work() on a workqueue.
Tearing those CQs down with ib_destroy_cq() frees them without first
cancelling that poll work.
If the provider posts a completion late -- for example Soft-RoCE (rxe)
posting an RNR error from rxe_receiver() after rdma_destroy_qp() -- the
handler re-queues ib_cq_poll_work() on the already-freed CQ, and a
follow-on access faults in rxe_req_notify_cq().
Use ib_free_cq(), which cancel_work_sync()es the poll work before freeing
the CQ, so no completion handler can run against a freed queue.
[ 1236.599526] ==================================================================
[ 1236.602142] BUG: KASAN: slab-use-after-free in ib_cq_poll_work+0xd0/0x1a0
[ 1236.605524] Read of size 8 at addr ffff888111865800 by task kworker/4:1H/82
[ 1236.609017]
[ 1236.609270] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Not tainted 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy)
[ 1236.609287] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 1236.609498] Workqueue: ib-comp-wq ib_cq_poll_work
[ 1236.609525] Call Trace:
[ 1236.609536] <TASK>
[ 1236.609545] __dump_stack+0x21/0x60
[ 1236.609562] dump_stack_lvl+0xc2/0x100
[ 1236.609573] print_address_description+0x77/0x200
[ 1236.609587] ? ib_cq_poll_work+0xd0/0x1a0
[ 1236.609597] print_report+0x58/0x70
[ 1236.609607] kasan_report+0x117/0x150
[ 1236.609623] ? ib_cq_poll_work+0xd0/0x1a0
[ 1236.609636] ? process_scheduled_works+0x954/0x1600
[ 1236.609650] ib_cq_poll_work+0xd0/0x1a0
[ 1236.609662] ? process_scheduled_works+0x954/0x1600
[ 1236.609674] process_scheduled_works+0xc22/0x1600
[ 1236.609698] ? __pfx_process_scheduled_works+0x10/0x10
[ 1236.609713] ? __pfx_assign_work+0x10/0x10
[ 1236.609726] ? lock_is_held_type+0x7b/0x110
[ 1236.609741] worker_thread+0x975/0xee0
[ 1236.609757] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 1236.609775] ? __kthread_parkme+0x21e/0x260
[ 1236.609789] kthread+0x3a6/0x490
[ 1236.609800] ? __pfx_worker_thread+0x10/0x10
[ 1236.609809] ? __pfx_kthread+0x10/0x10
[ 1236.609820] ret_from_fork+0x55a/0xa20
[ 1236.609835] ? __pfx_ret_from_fork+0x10/0x10
[ 1236.609850] ? __pfx_kthread+0x10/0x10
[ 1236.609861] ret_from_fork_asm+0x1a/0x30
[ 1236.609880] </TASK>
[ 1236.609886]
[ 1236.661292] Allocated by task 5076:
[ 1236.662640] kasan_save_track+0x3e/0x80
[ 1236.663842] __kasan_kmalloc+0x72/0x90
[ 1236.664763] __kmalloc_noprof+0x2b0/0x5d0
[ 1236.665356] __ib_alloc_cq+0x284/0x1000
[ 1236.666573] __ib_alloc_cq_any+0x23e/0x340
[ 1236.668654] smbdirect_connection_create_qp+0x6f7/0x1070
[ 1236.669757] smbdirect_accept_connect_request+0x500/0x1ca0
[ 1236.672625] smbdirect_listen_rdma_event_handler+0x1655/0x1c50
[ 1236.673930] cma_listen_handler+0x1bf/0x260
[ 1236.674923] cma_cm_event_handler+0x128/0x380
[ 1236.676926] cma_ib_req_handler+0x2d3d/0x4de0
[ 1236.678368] cm_process_work+0xb0/0x530
[ 1236.680454] cm_queue_work_unlock+0xb1/0x230
[ 1236.681673] cm_work_handler+0x969f/0xdca0
[ 1236.682704] process_scheduled_works+0xc22/0x1600
[ 1236.683447] worker_thread+0x975/0xee0
[ 1236.685901] kthread+0x3a6/0x490
[ 1236.688164] ret_from_fork+0x55a/0xa20
[ 1236.689522] ret_from_fork_asm+0x1a/0x30
[ 1236.690073]
[ 1236.690378] Freed by task 5137:
[ 1236.692242] kasan_save_track+0x3e/0x80
[ 1236.694272] kasan_save_free_info+0x40/0x50
[ 1236.695514] __kasan_slab_free+0x3a/0x60
[ 1236.696773] kfree+0x14e/0x4e0
[ 1236.697216] ib_destroy_cq_user+0x18d/0x250
[ 1236.699817] smbdirect_connection_destroy_qp+0xf2/0x280
[ 1236.702115] smbdirect_socket_destroy_sync+0x1607/0x2720
[ 1236.704062] smbdirect_socket_release+0x140/0x280
[ 1236.705286] smb_direct_free_transpor
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: destroy QP before mem pools on accept failure
On the rdma_accept_failed error path of
smbdirect_accept_connect_request(), the receive io posted just above is
owned by the QP (recv_io is set to NULL after a successful post). The
error path fell through to smbdirect_connection_destroy_mem_pools()
before smbdirect_connection_destroy_qp(), so the mem pools and the
recv_io slab cache were destroyed while that recv_io was still
outstanding on the QP.
The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what
runs the recv completion that returns the recv_io to the free list, so
destroying the pools first leaves the object outstanding at
kmem_cache_destroy() time ("Slab cache still has objects") and later
frees it into an already-destroyed mempool (mempool_free_bulk
NULL-pointer dereference).
Give rdma_accept_failed its own teardown that drains the QP first, then
destroys the mem pools, and returns. The remaining labels
(post_recv_io_failed onward) run before the recv_io was ever posted, so
they keep the mem-pools-then-qp order.
The outstanding recv_io at kmem_cache_destroy() time:
[ 3487.344647] =============================================================================
[ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown()
[ 3487.356078] -----------------------------------------------------------------------------
[ 3487.356078]
[ 3487.356738] Object 0xffff8881511c3440 @offset=13376
[ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254
[ 3487.361197] mempool_alloc_noprof+0x18c/0x290
[ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780
[ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80
[ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90
[ 3487.362779] cma_cm_event_handler+0x9c/0x230
[ 3487.363096] cma_ib_req_handler+0x2682/0x45d0
[ 3487.363414] cm_process_work+0x56/0x3d0
[ 3487.363676] cm_work_handler+0x8a0e/0xd000
[ 3487.367496] process_scheduled_works+0xa07/0x13a0
[ 3487.367859] worker_thread+0x7c9/0xc80
[ 3487.368148] kthread+0x341/0x430
[ 3487.368407] ret_from_fork+0x3a8/0x7a0
[ 3487.368704] ret_from_fork_asm+0x1a/0x30
[ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2)
[ 3487.372840] ------------[ cut here ]------------
[ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254
[ 3487.373759] Modules linked in:
[ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy)
[ 3487.374778] Tainted: [B]=BAD_PAGE
[ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 3487.378515] Workqueue: ib_cm cm_work_handler
[ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30
[ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
[ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093
[ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80
[ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080
[ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410
[ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210
[ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300
[ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000
[ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0
[ 3487.390440] PKRU: 55555554
[ 3487.390641] Call Trace:
[ 3487.390826] <TASK>
[ 3
---truncated--- |
