btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data()
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:
pinctrl: airoha: add missed IRQ resource helpers
Without hooking .irq_request_resources, gpiolib cannot set
GPIOD_FLAG_USED_AS_IRQ. This breaks pin direction locking and can allow
userspace or another driver to reconfigure an active IRQ pin as an output
Bluetooth: virtio_bt: avoid OOB read of build info string
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: virtio_bt: avoid OOB read of build info string
The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read
Build Information) and hands the response to bt_dev_info() and
hci_set_fw_info() as a "%s" string starting at skb->data + 1, without
checking the length. A backend that answers with status only leaves that
pointer past the end of the received data, so the walk reads adjacent
slab memory until it meets a NUL. Those bytes reach the kernel log and
the firmware-info debugfs file.
To fix this, print the string with a bounded "%.*s" limited to
skb->len
Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via
hci_conn_timeout (disc_work) -> hci_proto_disconn_ind ->
l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted
concurrently.
disc_work is disabled sync in hci_conn_del(), so we cannot take
hci_dev_lock in disc_work.
Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock
which is held in other access paths.
Bluetooth: hci_conn: fix the SCO setup context lifetime
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: fix the SCO setup context lifetime
hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so
the context is only freed if hci_enhanced_setup_sync() actually runs. An
entry that is cancelled instead is leaked, as
_hci_cmd_sync_cancel_entry() does not release entry->data when there is
no destroy callback, and hci_cmd_sync_clear() cancels every pending entry
when the controller is unregistered.
The context also stores a bare hci_conn pointer, so the connection can be
freed while the work is queued. The dequeue in hci_conn_del() does not
cov
Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths
adv_timeout_expire() hands a kmalloc()ed instance byte to
hci_cmd_sync_queue() with a NULL destroy callback, and only
adv_timeout_expire_sync() frees it. That leaks on two paths:
- the return value is not checked, and hci_cmd_sync_queue() does not
take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM);
- a cancelled entry is not released, as _hci_cmd_sync_cancel_entry()
does not free entry->data when there is no destroy callback.
hci_cmd_sync_clear() cancels every pending ent
Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
mesh_send_cancel() queues the pending command with a NULL destroy
callback, so it is only freed if send_cancel() runs. A cancelled entry is
leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when
there is no destroy callback, and hci_cmd_sync_clear() cancels every
pending entry when the controller is unregistered. Nothing else reclaims
it either: mgmt_pending_new() does not put the command on
hdev->mgmt_pending.
The leak also pins the socket reference taken by mgmt_pending_new(), so
t
Bluetooth: MGMT: free the HCI command when it is cancelled
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: free the HCI command when it is cancelled
mgmt_hci_cmd_sync() queues the pending command with a NULL destroy
callback, so it is only freed if send_hci_cmd_sync() runs. A cancelled
entry is leaked, as _hci_cmd_sync_cancel_entry() does not release
entry->data when there is no destroy callback, and hci_cmd_sync_clear()
cancels every pending entry when the controller is unregistered. Nothing
else reclaims it either: mgmt_pending_new() does not put the command on
hdev->mgmt_pending.
The leak also pins the socket reference taken by mgmt_pending_new(), so
the mgm
Bluetooth: MSFT: validate evt_prefix_len against the response length
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MSFT: validate evt_prefix_len against the response length
read_supported_features() only checks that the response covers the fixed
part of struct msft_rp_read_supported_features, which is 11 bytes:
if (skb->len < sizeof(*rp)) {
bt_dev_err(hdev, "MSFT supported features length mismatch");
goto failed;
}
evt_prefix[] is a flexible array member and rp->evt_prefix_len is an
unvalidated u8 taken straight out of that response, so
msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len,
GFP_KERNEL);
copies up to 255 bytes from a reply that may ha
bpf, cgroup: Fix storage null-ptr-deref after replacing prog
In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix storage null-ptr-deref after replacing prog
Syzkaller reported a storage null-ptr-deref issue after replacing prog.
This occurs in the following scenario:
1. prog A, an empty prog, is attached to a cgrp.
2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the
bpf_get_local_storage helper.
3. link_update is called to replace prog A with prog B.
The reason is that __cgroup_bpf_replace fails to alloc and assign the
required cgrp storage for the incoming replacement prog. Consequently,
the new prog inherits an uninit storage, leading to null-ptr-der
In the Linux kernel, the following vulnerability has been resolved:
iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
The IIO core does not filter duplicate writes to the event enable
attribute, so writing the same value twice invokes
write_event_config() twice. Enabling twice leaks a runtime PM
reference, preventing the device from ever suspending again;
disabling twice underflows the usage count and triggers a
"Runtime PM usage count underflow" warning.
Bail out early when the requested state matches the current state.
While at it, switch to pm_runtime_resume_and_get() so a failed
resume is propagated to userspace
net/sched: cls_api: fix teardown of an adopted proto on insert-race loss
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_api: fix teardown of an adopted proto on insert-race loss
In tc_new_tfilter() the create branch sets tp_created = 1 before calling
tcf_chain_tp_insert_unique(). When the caller loses the race (another
request inserted a proto at the same chain/prio first), insert_unique()
destroys the caller's own tp_new and returns the winner's proto with an
extra reference. tp_created was never cleared, so the loser's errout
path treated the winner's live proto as its own and called
tcf_chain_tp_delete_empty() on it, silently unlinking an active
classifier that the winning
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix mmap_lock leak in irq_work path
stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer
mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the
same mmap_unlock_work. Both callers only check whether the work is busy
before taking mmap_lock, so a nested caller can reuse the slot before the
first caller queues it. Two read locks may then be acquired while only one
deferred unlock runs, leaking a read lock and blocking exit_mmap().
Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper
in stackmap and bpf_find_vma()
apparmor: fix integer overflow in verify_tags() bounds check
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.
In the Linux kernel, the following vulnerability has been resolved:
fbdev: kyro: Validate overlay viewport coordinates
The overlay viewport end coordinates are computed from the viewport
origin and dimensions using 32-bit unsigned arithmetic. Large input
values can cause these calculations to wrap around before the resulting
coordinates are passed to SetOverlayViewPort().
SetOverlayViewPort() packs the viewport coordinates into 16-bit
register fields. The X coordinates are additionally adjusted by +2
and +1 before being written. Validate the coordinate calculations
for 32-bit wraparound and ensure that the adjusted coordinates fit
within t
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 driv
iommu/vt-d: Clear Present bit before tearing down copied context entry
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
iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
intel_iommu_attach_device() enables IOPF for the new domain but never
disables it for the old one. device_block_translation(), called at the
start of the function, tears down translation but does not touch any IOPF
state; blocking_domain_attach_dev() has to call iopf_for_domain_remove()
explicitly before invoking it for exactly this reason.
identity_domain_attach_dev() has the same problem. Its comment claims
that no PRI handling is needed because the device has been put in the
blocking state, but the blocking
iommu/vt-d: Tear down scalable-mode context on probe failure
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 a
iommu/vt-d: Flush context cache with correct SID when tearing down aliases
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