s390/vfio_ccw: Fix out of bounds check on CCW array
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Fix out of bounds check on CCW array
The routine ccwchain_calc_length() counts the number of channel
command words (CCWs) that are chained together in a single channel
program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs.
The loop itself is "do..while (count < 257)", and while the logic in
is_cpa_within_range() correctly adjusts between the 0-index array of
CCWs and the count of CCWs starting at 1, this means it would look
at a possible 257th CCW before ending the loop and (correctly)
returning an error.
Fix this by restructuring the loop t
s390/vfio_ccw: Move cp cleanup out of not operational
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been
lost, and is (by definition) no longer operational. Since this
can happen asynchronously from the normal behavior of the
driver, the cleanup may happen when holding other locks
in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue,
where it can be done out from under that lock sequence and
a future patch can safely manage the locking requirements.
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Selectively expand io_mutex
The io_mutex was defined to serialize the io_regions, but then has
also sort of been associated with the I/O themselves because of
the close relationship they share.
With the handful of races that are possible, the choices are either to:
A) expand the scope of io_mutex to close these remaining windows, or
B) reduce the scope of io_mutex to just io_region, and introduce a new
lock mechanism for the remaining I/O resources
This patch implements A, since B brings with it a lot more interactions
that would need to be tracked an
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Implement a crw lock
Unlike the channel_program struct, which covers synchronous I/O
submissions and asynchronous interrupts, the CRW region relies
exclusively on asynchronous events coming from hardware.
Implement a lock to manage the list of those payloads, to ensure
they are read cohesively.
drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank()
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank()
amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when
vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before
a stream is attached to it.
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu]
Call Trace:
drm_vblank_enable
drm_vblank_get
drm_crtc_get_sequence_ioctl
drm_ioctl_kernel
drm_ioctl
Reproduced by running VKCTS with WSI tests enabled on RADV.
Guard the enable path on acrtc_state->stream being non-
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate GEM_CREATE domain combinations
AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK,
but did not validate domain combinations. Userspace could combine
CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making
amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and
hit BUG_ON().
Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/
VRAM domains to be specified one at a time. Return -EINVAL for invalid
combinations in amdgpu_gem_create_ioctl().
v2: Rename helper from amdgpu_gem_domain_valid() to
amdgpu_gem_are
drm/amdgpu: Fix UVD decode image min size calculation
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix UVD decode image min size calculation
This needs to use pitch instead of width. Also reject pitch
over 4096 to avoid overflow.
(cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)
drm/amdgpu: disallow multiple FENCE chunks in one submit
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: disallow multiple FENCE chunks in one submit
amdgpu_cs_pass1() dispatches on chunk_id once per chunk without
rejecting repeated ids. p->uf_bo is a single-slot field, so a
submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs
amdgpu_cs_p1_user_fence() twice, and the second run overwrites
p->uf_bo with a freshly referenced BO without dropping the reference
taken by the first.
amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE
chunk but the last leaks a BO reference. The leaked BO outlives handle
close and process exit.
Reject duplicate FE
In the Linux kernel, the following vulnerability has been resolved:
xfs: propagate errors from xfs_rtginode_load
xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than
-ENOENT as success. This can leave the realtime group inode unset after an
I/O, allocation, or corruption error. Growfs then continues as though the
inode had been loaded.
Only -ENOENT means that the inode needs to be created. Return all other
errors to the growfs caller.
xfs: fix off-by-one in rtrefcount btree root level validation
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix off-by-one in rtrefcount btree root level validation
xfs_rtrefcountbt_compute_maxlevels() sets
mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1;
where the trailing "+ 1" already accounts for the inode-root level, so the
deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must
satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels).
The two on-disk validation paths, xfs_rtrefcountbt_verify() and
xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a
crafted rtreflink (metadir + realtime + reflink) image whos
In the Linux kernel, the following vulnerability has been resolved:
xfs: bounds-check buffer log item's dirty bitmap
xlog_recover_do_reg_buffer() replays each dirty region described by a
buffer log item's bitmap into the buffer read for that item:
memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT),
item->ri_buf[i].iov_base,
nbits << XFS_BLF_SHIFT);
The destination offset (bit/nbits, from the logged dirty bitmap) and the
buffer size (from the logged blf_len) are both attacker-controlled and
otherwise unrelated, yet the only thing bounding the copy is an ASSERT(),
which compiles away on production kernels. A crafted image logging a
xfs: don't double-lock when deleting a self-referential directory
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't double-lock when deleting a self-referential directory
LOLLM notices that the dirtree scrubber can detect a directory that
refers to itself. In this case, it's not correct for the directory tree
repair code to try to iolock/ilock both sc->ip and dp, because they're
the same inode. Fix this by detecting that corner case and handling it
appropriately.
xfs: fix ilock leak on error in xfs_dq_get_next_id
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix ilock leak on error in xfs_dq_get_next_id
xfs_dq_get_next_id() takes the quota inode ILOCK before calling
xfs_iread_extents(). If xfs_iread_extents() fails, the function returns
immediately without releasing the lock, leaking the quota inode ILOCK.
This can leave the quota inode locked and cause subsequent quota
operations to hang.
Fix this by jumping to a common unlock path on error instead of returning
directly.
xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair
LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket
tries to walk ragi->sc->sa.agi_bp to rebuild the unlinked inode lists.
Unfortunately, it's possible for agi_bp to be null if the buffer
verifier fails, so we have to use ragi->agi_bp (which skips verifier
checks) instead.
xfs: fix another iunlink infinite loop bug in online fsck
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix another iunlink infinite loop bug in online fsck
xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the
incore prev and next unlinked list pointers based on what it finds on
disk and in memory before we move on to relinking the truly lost inodes
back into the unlinked list. However, it's still vulnerable to infinite
loops that come in via the next_unlinked pointers.
Fix this problem by remembering which inodes we've already seen and
checking new agino pointers against that. If a bit is already set,
either this is a loop or the inode has nonzero li
xfs: avoid UAF on sc->tempip in xrep_tempfile_create
In the Linux kernel, the following vulnerability has been resolved:
xfs: avoid UAF on sc->tempip in xrep_tempfile_create
LOLLM noticed a potential UAF if the tempfile creation code fails after
it set sc->tempip. Fix that.
xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
When exchanging two full-file ranges, xmi_can_exchange_reflink_flags()
can move the reflink inode flag from the file that currently has it to
the other file, as long as exactly one side is marked. This assumes
that the file contents, and therefore all shared extents, are exchanged.
That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set.
xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings
from file1, so an exchange can complete without moving every mapping
that the earlier fla
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't swallow dquot recovery verification errors
xlog_recover_dquot_commit_pass2() validates the recovered dquot with
xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps
to out_release. But out_release unconditionally returns 0, so the
corruption error is discarded: the caller xlog_recover_items_pass2()
sees success, log recovery proceeds as if the dquot were valid, and the
corrupt quota buffer can be written back to disk.
ceph: avoid fs reclaim while using current->journal_info
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid fs reclaim while using current->journal_info
handle_reply() stores a `ceph_mds_request` pointer in
`current->journal_info` while filling the inode and dentry cache from
an MDS reply.
An allocation in this section can enter direct reclaim and prune
dentries from another filesystem. If this dirties an ext4 inode, ext4
starts a JBD2 transaction. JBD2 interprets the Ceph request in
`current->journal_info` as a journal handle and dereferences the
request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.:
Unable to handle kernel paging request at virtual
ceph: fix hanging __ceph_get_caps() with stale mds_wanted
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix hanging __ceph_get_caps() with stale mds_wanted
A reader can hang forever in __ceph_get_caps() when the client no
longer holds `FILE_RD`, but local cap state still says that the
capability is already wanted (via `mds_wanted`).
One way to trigger this is through MDS cap revocation. If another
client performs a conflicting operation, the MDS can revoke `FILE_RD`
from the reader; the next read then has to reacquire `FILE_RD`. If
the cap update that should request `FILE_RD` never reaches the MDS
after `cap->mds_wanted` was raised, the reader is left holding only
no