| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
smb/server: call ksmbd_proc_cleanup() on module init failure
When a later initializer fails, the unwind chain releases resources
created after procfs and then jumps directly to class_unregister().
Returning an error from module_init() leaves the proc tree and its
per-CPU counters allocated. |
| In the Linux kernel, the following vulnerability has been resolved:
smb/server: abort initialization when proc setup fails
ksmbd_server_init() calls ksmbd_proc_init() before creating the
remaining proc entries and server subsystems. ksmbd_proc_init() tears
down partial state on a procfs or percpu_counter allocation failure,
but returns void, so ksmbd_server_init() continues as if the counters
were usable.
Once userspace starts the server, server_ctrl_handle_init() calls
ksmbd_proc_reset(), which reaches percpu_counter_set() with a NULL
per-CPU counters pointer on SMP systems. The later ksmbd_proc_create()
calls also receive a NULL parent and may create entries in the /proc
root; ksmbd_proc_cleanup() cannot remove those entries because
ksmbd_proc_fs is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request()
See the procedure below:
ksmbd_tree_conn_connect
ksmbd_share_config_get
share->name = kstrdup() // fail
if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false
// do not check `share->name`
ksmbd_ipc_tree_connect_request
strlen(share->name) // null-ptr-deref |
| 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--- |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Check pointer type for all atomic RMW paths
Atomic RMW verification records an instruction pointer type only when the
current destination is PTR_TO_ARENA. A second path can therefore reach the
same instruction with an ordinary pointer without comparing it against the
saved arena type.
The post-verification fixup uses the saved type to rewrite the instruction
to BPF_PROBE_ATOMIC for every path. Record the actual destination type for
all atomic RMW paths so the existing mismatch check rejects incompatible
uses of one instruction. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: clear delay state when freeing policy data
io.latency can throttle a group which has no latency target of its own.
When a sibling misses its target, check_scale_change() scales down its
peers, and a peer that reaches queue depth one gets blkcg_use_delay()
called on it on every further scale-down, even with min_lat_nsec == 0.
iolatency_pd_offline() resets the target through
iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero
to zero transition, so it never clears such a peer. Freeing the policy
data then leaves blkg->use_delay set and blkcg->congestion_count
elevated with nothing left that can drop it.
blk_cgroup_congested() then returns true for every task in that cgroup
and its descendants for as long as the cgroup lives: page_cache_sync_ra()
cuts readahead to a single page, page_cache_async_ra() skips it
altogether, and __folio_throttle_swaprate() takes swap_avail_lock and
schedules a throttle on anonymous folio allocation.
Clear the delay in iolatency_pd_free(). By then bio-held blkg
references have drained, or the queue is frozen for policy
deactivation, so check_scale_change() cannot re-arm it. The free
callback can also see policy data which was never attached to a blkg,
hence the pd->blkg check. |
| In the Linux kernel, the following vulnerability has been resolved:
null_blk: serialize configfs attribute updates with device setup
The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to
change the configuration of a live device by testing
NULLB_DEV_FL_CONFIGURED, but that flag is only set by
nullb_device_power_store() after null_add_dev() has returned, and the
store methods take no lock at all. configfs only serializes writes to
the same open file (buffer->mutex), so a write to any attribute can run
concurrently with null_add_dev() and change the device configuration
while it is being used.
null_add_dev() reads the configuration several times, e.g. dev->zoned is
read once to set up the queue limits and once to initialize the zone
resources:
CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned
nullb_device_power_store()
mutex_lock(&lock)
null_add_dev()
if (dev->zoned) -> false
/* no BLK_FEAT_ZONED */ nullb_device_zoned_store()
test_bit(FL_CONFIGURED) -> 0
dev->zoned = true
blk_mq_alloc_disk()
/* queue is not zoned */
if (nullb->dev->zoned) -> true
null_register_zoned_dev()
blk_revalidate_disk_zones()
blk_revalidate_disk_zones() is then called for a queue that does not
have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the
device setup with -EIO:
WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560
Clearing dev->zoned in the same window is worse: the queue is created
with BLK_FEAT_ZONED but the zone resources are never initialized, so
add_disk() succeeds for a zoned disk that has no zones. And a store that
lands after the last dev->zoned test leaves dev->zoned set while
dev->zones is still NULL, which null_process_zoned_cmd() dereferences on
the first write.
Fix this by taking the global lock, which nullb_device_power_store()
already holds across null_add_dev() and null_del_dev(), around both the
NULLB_DEV_FL_CONFIGURED test and the update of the device configuration.
The submit_queues and poll_queues apply callbacks are now called with
that lock held, so remove the locking they did themselves.
Since the store methods can run as soon as configfs_register_subsystem()
returns, that is, before null_init() gets to mutex_init(&lock), also
initialize the lock statically with DEFINE_MUTEX(). |
| In the Linux kernel, the following vulnerability has been resolved:
IB/isert: delay the final Login Response until the session is registered
isert_put_login_tx() puts the final Login Response on the wire before
__transport_register_session(), which iscsi_post_login_handler() reaches
only after iscsi_target_do_login() returns. An initiator that issues a
SCSI command as soon as it sees that response can have it executed against
an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses
on the NULL dereference.
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: ib-comp-wq ib_cq_poll_work
RIP: 0010:target_submit+0xbe/0x390
Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00
RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363
RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078
RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52
R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000
R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044
FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
<TASK>
? __pfx__raw_spin_lock_bh+0x10/0x10
? __pfx_target_submit+0x10/0x10
? mutex_lock+0x81/0xe0
? __pfx_mutex_lock+0x10/0x10
? iscsit_execute_cmd+0x650/0x850
iscsit_sequence_cmd+0x186/0x3d0
iscsit_process_scsi_cmd+0x87/0x300
isert_recv_done+0x1002/0x2390
? __pfx_isert_recv_done+0x10/0x10
? rxe_poll_cq+0x253/0x3d0
? finish_task_switch.isra.0+0x1dc/0xa70
__ib_process_cq+0xe1/0x390
ib_cq_poll_work+0x46/0x150
process_one_work+0x633/0x1030
? assign_work+0x11d/0x370
worker_thread+0x45b/0xd10
? __pfx_worker_thread+0x10/0x10
? __pfx_worker_thread+0x10/0x10
kthread+0x2c6/0x3b0
? recalc_sigpending+0x15c/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x36e/0x5a0
? __pfx_ret_from_fork+0x10/0x10
? __switch_to+0x572/0xdd0
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
Delay the final Login Response instead. isert_get_rx_pdu() runs from
iscsi_target_rx_thread() after conn->rx_login_comp, completed by
iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP
and cxgbit already take PDUs from that thread, isert alone does not. The
buffers are still posted first, so the initiator's first command does not
meet an empty receive queue and nothing depends on RNR flow control, and
the header and payload live in isert_conn, not in the struct iscsi_login
that iscsi_target_nego_release() frees first.
Over rxe, 400 login cycles per run, the oops appeared in 10 of 20
unpatched runs and in none of 20 runs with this patch. An
initiator that never waits is handled by the next patch.
Not tested: iWARP, discovery sessions over iSER, and real HCAs. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Check atomic pool allocation result directly
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(),
which returns the allocated page and fills cpu_addr only on success.
Do not rely on cpu_addr to detect allocation failure in this path. Check
the returned page directly before using it for the IOMMU mapping. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix integer overflow of user QP buffer size
set_user_buf_size() computes the QP buffer size by left-shifting the
user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers.
A sufficiently large rq.wqe_cnt causes signed integer overflow, which
is undefined behavior, and yields a small or negative buf_size, causing
ib_umem_get() to map a buffer smaller than the hardware will actually
write into.
Replace the shifts and addition with check_shl_overflow() and
check_add_overflow(), rejecting invalid user inputs.
Moreover, guard the identical shift computing qp->sq.offset in
_create_user_qp() before set_user_buf_size() is reached. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup
vddInd and vddcInd fields from VBIOS-parsed tables are used to index into
voltage lookup tables without a bounds check. Return -EINVAL when any
index is out of range. |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler
qcom_cpucp_mbox_irq_fn() calls mbox_chan_received_data() while holding
chan->lock. Under PREEMPT_RT, spin_lock_irqsave() is converted to an
rt_spinlock (rtmutex-based), which tracks ownership and can sleep.
The callback chain triggered by mbox_chan_received_data() eventually
reaches mailbox_clear_channel() -> mbox_send_message() -> add_to_rbuf(),
which attempts to re-acquire the same chan->lock. Since rtmutex detects
the re-entrant lock attempt by the same owner, the thread blocks waiting
for a lock it already holds, causing a permanent deadlock.
This deadlock manifests as 'irq/N-apss_cpucp_mbox' stuck in D state
with the following call trace:
rt_spin_lock -> mbox_send_message -> mailbox_clear_channel ->
scmi_rx_callback -> mbox_chan_received_data [<- held chan->lock here]
Fix by saving chan->cl locally and clearing the HW interrupt register
inside the lock, then invoking mbox_chan_received_data() after releasing
the lock. This preserves the mutual exclusion for chan->cl access while
avoiding the lock re-entrancy that causes the PREEMPT_RT deadlock. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: scan: fix bus ID cleanup on device_add() failures
When device_add() fails after acpi_device_set_name() has allocated an
instance ID and a new acpi_device_bus_id has been linked into
acpi_bus_id_list, the rollback path only removes wakeup_list and
detaches the ACPI handle data.
That leaves the bus-ID bookkeeping behind and keeps the allocated
instance number consumed.
Move the bus-ID cleanup and wakeup-list removal into a single helper.
Use it from both the normal device teardown path and the device_add()
rollback path. The wakeup list node is initialized before registration,
so it can be deleted without checking whether the device is wakeup-
capable like in the original teardown path.
[ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ]
[ rjw: Subject and changelog edits ] |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: validate topology volume range before allocation
SOF treats the topology mixer min and max values as non-negative indices
into its volume table. It stores them in signed fields, allocates max + 1
entries through an int argument, and later indexes the table with the
stored range.
An inverted range is invalid, while a maximum at or above INT_MAX cannot
be represented safely after the increment or in the signed fields.
Validate the complete range before storing it or allocating the table. |
| 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:
fs/ntfs3: fix integer overflow in MFT cluster validation
In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are
validated against the volume size with:
if (mlcn * sct_per_clst >= sectors ||
mlcn2 * sct_per_clst >= sectors)
goto out;
mlcn and mlcn2 are u64 fields read directly from the boot sector.
sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus
the is_power_of_2() check below it), but the multiplication is done
in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn
near 2^62 with sct_per_clst == 4 wraps to 0, which compares below
any non-zero 'sectors', so the check is bypassed and the malformed
record is accepted.
The accepted mlcn is then used unchanged in
sbi->mft.lbo = mlcn << cluster_bits;
In practice the resulting reads fail at the block layer (sb_bread()
returns NULL via grow_buffers()'s check_mul_overflow() guard), so
today this manifests as mount failing in odd places rather than as
something more dangerous, but the validation step is still wrong
and there is no reason for callers to rely on the block layer to
catch a value that should never have been accepted in the first
place.
Use check_mul_overflow() to compute the two sector positions and
fail the mount if either multiplication wraps; this preserves the
existing semantics (mlcn * sct_per_clst >= sectors) instead of
switching to division (mlcn >= sectors / sct_per_clst), which
would tighten the check at edge cases where 'sectors' is not a
multiple of sct_per_clst. The check_*_overflow() style is the
one ntfs3 already uses for similar on-disk arithmetic in
fs/ntfs3/run.c. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()
When a host issues an Identify command with CNS 05h (I/O Command Set
specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed
namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on
req->ns->bdev. A file-backed namespace has no block device, so
req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing.
The I/O command set is selected by the host-supplied CSI field and the
command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled,
independent of the namespace backing type, so any file-backed namespace
is exposed.
Reject the command with Invalid Field when the namespace is not backed
by a block device. |
| In the Linux kernel, the following vulnerability has been resolved:
media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path
isp4sd_pwron_and_init() holds ops_mutex via guard(mutex) and, on any
init failure, jumps to err_deinit and calls isp4sd_pwroff_and_deinit().
That helper takes the same ops_mutex, re-acquiring a non-recursive mutex
already held by the current thread, so any init failure deadlocks.
Unwind the error path in stages instead, releasing only what each
failure point acquired. This also avoids the issues that an
unconditional teardown would hit at the earlier failures, such as a
runtime-PM underflow from pm_runtime_resume_and_get() and MMIO access
while the device is unpowered. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Flush cached MSI write before unmapping the iATU
The MSI-X path already flushes any posted MSI-X write before tearing down
its iATU mapping. That was added by commit c22533c66cca ("PCI: dwc: ep:
Flush MSI-X write before unmapping its ATU entry") to make sure the write
reaches the Root Complex before the outbound window that translates it
disappears.
The MSI path has the same problem but no equivalent flush. When the
Endpoint driver caches an MSI target address and later observes that the
Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing
iATU entry and reprograms it for the new address. Between the last MSI
writel() and the unmap there may still be a posted write sitting in the
fabric, and unmapping the iATU entry can drop or misroute that write.
Fix this by reading back from the mapped MSI window before the unmap. The
readback drains any posted MSI writes through the same iATU entry that
mapped them, which is the same logic the MSI-X path uses.
[mani: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Preserve allocation virtual address for dynamic pools
swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted
pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the
atomic pool is backed by remapped virtual addresses, which are not the same
as the direct-map addresses returned by phys_to_virt().
swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address
from the physical start address. For atomic-pool backed allocations this
stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes
that address to dma_free_from_pool(), which will fail to recognize the
chunk
Pass the virtual address returned by the allocation path into
swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This
keeps the pool free path using the same virtual address as the allocator. |
