smb: client: pin DFS superblock in iterator callback
In the Linux kernel, the following vulnerability has been resolved:
smb: client: pin DFS superblock in iterator callback
tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super()
takes its active reference only after iterate_supers_type() has dropped
s_umount and its passive reference. Concurrent DFS automount expiry can
therefore free the superblock before cifs_sb_active() uses it.
A deterministic KASAN test reproduces the race as:
BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80
The same test passes with this change applied.
Take the active reference in the callback while iterate_supers_type()
still holds s_
smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid
In the Linux kernel, the following vulnerability has been resolved:
smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid
When the administrator mounts with forceuid or forcegid (uid=/gid=
mount options), they expect all files to appear owned by the specified
user/group. However, several code paths unconditionally called
sid_to_id() to overwrite cf_uid/cf_gid with server-provided values,
ignoring the administrator's explicit override:
- smb311_posix_info_to_fattr() (stat via POSIX extensions)
- cifs_posix_to_fattr() (readdir via POSIX extensions)
- parse_sec_desc() (CIFS ACL ownership mapping)
This allowed an untrusted
smb: client: fail DACL rewrite when the new DACL exceeds 64K
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fail DACL rewrite when the new DACL exceeds 64K
replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of
the DACL they build in a u16. That accumulator can wrap.
validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) /
20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can
grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with
one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is
therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond
what a u16 can hold. A wrapar
smb: client: fix cifsFileInfo reference leak in deferred close
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix cifsFileInfo reference leak in deferred close
When cifs_close() defers a close, it hands the cifsFileInfo reference
of the closing struct file to the queued work. Each execution of
smb2_deferred_work_close() drops one such reference.
deferred_close_scheduled can be false while the work is pending: the
workqueue clears PENDING when the callback starts to run, before the
callback clears the flag under deferred_lock. A close in that
interval requeues the running work, and the callback then clears the
flag, leaving the requeued work pending with the flag down.
smb: client: avoid leaking refcount in cifs_queue_oplock_break()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: avoid leaking refcount in cifs_queue_oplock_break()
cifs_queue_oplock_break() unconditionally takes a reference on the
target file before queueing cifs_oplock_break(). Only that work item
decreases the reference counter again.
If another oplock break arrives while that work is still queued,
queue_work() will return false and not queue this second work item. As a
result, we will never reach the point to drop the file reference again
and are leaking this reference. This can be triggered when interacting
with a slow-responding server.
As a result, later unmount
smb: client: avoid leaking refcount when cifs_sb_tlink() fails
In the Linux kernel, the following vulnerability has been resolved:
smb: client: avoid leaking refcount when cifs_sb_tlink() fails
cifs_oplock_break() takes over the reference that
cifs_queue_oplock_break() acquired when it queued the work, and drops it
with _cifsFileInfo_put() once the break has been processed.
Only in setups with "-o multiuser", cifs_sb_tlink() may fail, at which
point cifs_oplock_break() returns without putting the file reference,
mirroring the reference leak we already fixed in the companion patch to
cifs_queue_oplock_break().
This would trigger a crash due to busy inodes on the next unmount:
BUG: Dentry ... still
smb: client: fix heap overflow in DACL owner/group rewrite
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix heap overflow in DACL owner/group rewrite
When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a
buffer sized according to the on-disk DACL length reported by
dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each
ACE with a new owner/group SID obtained from the cifs.idmap upcall.
Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities,
making each ACE up to 76 bytes (sizeof(struct smb_ace)).
If the original DACL contains short SIDs (e.g., 1 sub-authority) while
the replacement SIDs are long, the rewritten ACEs over
smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()
cifs_posix_to_fattr() ignores the return value of posix_info_parse().
When a malformed POSIX directory entry is encountered (e.g. invalid
SID lengths from an untrusted server), posix_info_parse() returns -1
without populating the 'parsed' struct. The uninitialized stack
memory in parsed.owner and parsed.group is then passed to
sid_to_id(), which processes the garbage bytes and passes them to
request_key() to construct a SID string, potentially leaking kernel
stack contents to the userspace idmap daemon.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: don't store usb_device_id
usb_device_id is not guaranteed to live longer than probe due to presence
of dynamic ID. All information apart from driver_data can be easily
retrieved from usb_device, so just store driver_data.
net: usb: pegasus: don't rely on id table pointer arithmetic
In the Linux kernel, the following vulnerability has been resolved:
net: usb: pegasus: don't rely on id table pointer arithmetic
The current code is broken when dynamic ID is involved; in such cases
usb_device_id parameter of probe lives on the heap and the pointer
arithmetic will get an index that is wildly out of bound. Instead of
keeping a side table for additional information, use driver_info field of
the usb_device_id.
The dynamic ID parsing code needs to be updated for this; convert it to
just write to the reserved entry for dynamic ID and remove the weird loop.
usb: xusbatm: don't rely on id table pointer arithmetic
In the Linux kernel, the following vulnerability has been resolved:
usb: xusbatm: don't rely on id table pointer arithmetic
The current code is broken when dynamic ID is involved; in such cases
usb_device_id parameter of probe lives on the heap and the pointer
arithmetic will get an index that is wildly out of bound. xusbatm
initialize the USB device IDs dynamically so it can just use driver_info
too.
Even with conversion, xusbatm still cannot support dynamic IDs, so also set
no_dynamic_id.
scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking
qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing
bugs exposed on the error path of qla25xx_create_{req,rsp}_que():
1. When dma_alloc_coherent() fails during queue creation, the error
path calls the free function with req->ring / rsp->ring still NULL
(from kzalloc). The unconditional dma_free_coherent() with a NULL
cpu_addr is undefined behavior and can panic.
2. The free functions clear req_qid_map / rsp_qid_map under vport_lock,
but the create functions protect th
scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair->qp_lock.
During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha->wq. A still-pending q_work then runs
qla_do_work() against the freed q
scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size
The VP control IOCB selects its target virtual port by setting one bit
in vp_idx_map, a fixed 16-byte (128-bit) array in both
vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb()
computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map]
without checking that map stays within the array.
max_npiv_vports is taken from firmware and only sanitized to a
MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or
255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports.
f2fs: accurately adjust free_sections during free_segment_range
In the Linux kernel, the following vulnerability has been resolved:
f2fs: accurately adjust free_sections during free_segment_range
In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs`
to restrict block allocation to the safe remaining main area while valid
blocks in the truncated range are evacuated by GC.
However, FREE_I(sbi)->free_sections tracks the total number of free
sections across the whole filesystem. If any sections within the
truncated range were already free upon entering free_segment_range(),
failing to deduct them from free_sections causes the filesystem to
overestimate available free sections in the acti
scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path
When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to
probe_hw_failed and calls qla2x00_mem_free(). Several error labels in
qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool,
flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info)
but left the pointers dangling. qla2x00_mem_free() then freed them a
second time. Worse, for the dma_pool members it issued
dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been
destroyed and set to NULL at fail_s_dma_p
scsi: qla2xxx: Skip vport under deletion in report ID acquisition
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Skip vport under deletion in report ID acquisition
qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under
vport_slock, takes a vref_count on the matching vport and calls
qla_update_host_map() to register its port id.
A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then
qla24xx_disable_vp() removes the vport from the host_map btree and zeroes
vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later,
in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX)
but does not touch host_map. In the window
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll
rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide
whether the next continuation IOCB has arrived, spinning on cpu_relax()
without advancing the ring or decrementing the entry count while it has
not. response_t::signature lives at byte offset 60, but a continuation
IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame
payload at that offset (data[56..59]). A received frame whose payload
bytes happen to equal
scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]
The FC BSG transport allocates job->request via memdup_user() using the
exact user-supplied request_len. For FC_BSG_HST_VENDOR,
fc_bsg_host_dispatch() only guarantees request_len covers msgcode and
vendor_id; it does not account for the vendor_cmd[] flexible array.
qla2xxx then reads the command selector vendor_cmd[0] and, in several
sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor
command area without verifying request_len. A caller holding
CAP_SYS_RAWIO can submit a short request whos
In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid unneeded actions on subflow reset
Once in a blue moon, the mptcp receive path can recursively call
mptcp_data_ready() via state change under unlucky error conditions, and
then try to hold the data lock again.
Break the recursion loop explicitly checking for the exceptional
condition.
Add a new flag instead of using an existing one like 'closing', to exit
early in subflow_state_change(), and explicitly flush the RX queue at
reset time.
This avoids unneeded processing to check for available data -- calling
get_mapping_status() and more on a dying subflow -- bu