bpf: Invalidate RCU pointers after final spin unlock
In the Linux kernel, the following vulnerability has been resolved:
bpf: Invalidate RCU pointers after final spin unlock
In a sleepable BPF program, a spin lock can provide the only RCU protection
for a kptr. The final bpf_spin_unlock() ends that protection, but the
verifier leaves the pointer valid. Another CPU can then free the object
before the pointer is used. A capability-limited runtime PoC triggered a
task_struct use-after-free in __bpf_get_task_stack().
Record whether the program is in an RCU-protected context before releasing
the lock. Invalidate RCU-protected pointers only when the unlock leaves the
final such context. This prese
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers
In the Linux kernel, the following vulnerability has been resolved:
PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers
Currently, the legacy I/O and memory sysfs handlers do not check
security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and
legacy_mem files unprotected when the kernel is locked down.
Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked
down") added the check to pci_write_config(), pci_mmap_resource(), and
pci_write_resource_io() to prevent userspace from programming DMA-capable
hardware that could be used to modify kernel code, but did not cover the
legacy handlers.
As a resu
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
thermal: hwmon: Remove hwmon class device along with its parent
In the Linux kernel, the following vulnerability has been resolved:
thermal: hwmon: Remove hwmon class device along with its parent
The current code creates one hwmon device per thermal zone type and that
device is registered under the first thermal zone of the given type.
That turns out to be problematic when the thermal zone holding the
hwmon device is removed.
For example, say that there are two ACPI thermal zones on a system
/sys/devices/virtual/thermal/thermal_zone0/
/sys/devices/virtual/thermal/thermal_zone1/
The current code registers a hwmon class device for thermal_zone0 only:
/sys/devices/virtual/thermal/thermal_zone0/hwmo
ocfs2: o2hb: quiesce negotiate handlers and timeout work
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: o2hb: quiesce negotiate handlers and timeout work
Heartbeat regions publish struct o2hb_region as the private data for the
NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item()
creates the configfs region. The approve handler can call
o2hb_arm_timeout(), so a peer can touch the region timeout work before
dev_store() has finished building the heartbeat runtime, or after teardown
has started to shut that runtime back down.
The final configfs put also has to keep reg alive until the last in-flight
o2net callback drops its handler reference.
o2net_unregi
In the Linux kernel, the following vulnerability has been resolved:
bpf: Clear buf on error in __bpf_get_task_stack
Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that
use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM
argument and we should initialize the buf on every return path.
Adding missing buf memset for __bpf_get_task_stack fail paths. This
provides deterministic buffer contents, which is useful when the buffer
is used directly as a map key.
drm/amd/display: Resize MST HDCP per-connector arrays to 32
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Resize MST HDCP per-connector arrays to 32
AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of
32 connectors. But the way it's used is like MAX_DISPLAY_COUNT.
Hence we're off by one with DRM core, which supports a max of 32
connectors.
Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT
to match its actual use, and increase the size to 32 to match the
originally intended size.
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
In the Linux kernel, the following vulnerability has been resolved:
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
In the perf enable path, there are missing cases where
cscfg_csdev_disable_active_config() is not called:
- Branch broadcast is selected but not supported by the hardware
- etm4_enable_hw() fails
This can lead to a leak of config_desc->active_cnt.
Fix this by properly calling cscfg_csdev_disable_active_config()
in these error paths.
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails
In the Linux kernel, the following vulnerability has been resolved:
scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails
sd_set_special_bvec() allocates a special payload page for UNMAP and
WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in
sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI
midlayer does not call uninit_command() because RQF_DONTPREP is not set
yet, leaking the page.
Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after
freeing the page.
btrfs: defrag: fix deadlock between defrag and delalloc space reservation
In the Linux kernel, the following vulnerability has been resolved:
btrfs: defrag: fix deadlock between defrag and delalloc space reservation
While running fsstress with autodefrag and flushoncommit, hit a deadlock
due to the fact that defrag reserves delalloc space while it's holding
dirty and locked folios, besides the extent range lock. The stack traces
are the following:
[958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000
[958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[958.627] Call Trace:
[958.628] <TASK>
[958.628] __
btrfs: always wait for ordered extents to avoid OE races
In the Linux kernel, the following vulnerability has been resolved:
btrfs: always wait for ordered extents to avoid OE races
[BUG]
Syzbot reported a bug that there can be conflicting OEs for the same
range:
BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384
btrfs: check if root is readonly when setting posix acl
In the Linux kernel, the following vulnerability has been resolved:
btrfs: check if root is readonly when setting posix acl
For a filesystem which has btrfs read-only property set to true, all
write operations including acl and xattr should be denied. However, acl
can still be set even if btrfs ro property is true.
This happens because no function on the set_acl code path checks the root
is readonly or not. It was checked in btrfs_setxattr_trans() but got
removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root
check in btrfs_setxattr_trans")
That commit didn't check if all the callers properly check the root's
read-only fla
btrfs: zoned: flush active metadata block group at btree_writepages() start
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: flush active metadata block group at btree_writepages() start
btree_writepages() writes the btree inode's dirty metadata in ascending
logical address order. On a zoned filesystem only one metadata and one
system block group is active for writing at a time, and
check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the
active block group as writeback moves from one block group to the next.
If the active block group sits at a higher logical address than another
block group that also holds dirty metadata, the ascending walk reaches
the lower one firs
btrfs: zoned: don't clobber the extent buffer when zeroing it out
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: don't clobber the extent buffer when zeroing it out
On a zoned filesystem a freed-but-still-dirty tree block is written out
as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write
pointer advancing. btree_csum_one_bio() implemented this by memzeroing
the extent buffer's own folios before submission.
That destroys the in-memory buffer while it may still be referenced. In
particular btrfs_free_tree_block() can run on it afterwards and reads
the header to add a delayed reference; once the header has been zeroed
it frees bytenr 0 and corrupts the exten
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.
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.
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
bpf: Fix mmap_lock leak in irq_work path
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()
netfilter: nft_ct: move custom expectation support to helper
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 ("netfi
NFS: Return a delegation the client fails to record
In the Linux kernel, the following vulnerability has been resolved:
NFS: Return a delegation the client fails to record
When an NFS server grants a delegation in an OPEN reply,
nfs_inode_set_delegation() records it on the client. However, three
of its error flows return without sending DELEGRETURN.
A delegation can be relinquished only by DELEGRETURN (RFC 8881
Section 20.2.4), so dropping one silently leaves the server believing
the client still holds it. If the server happens to recall that
delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE
because it has no record of the stateid. The server revokes the
delegation and moves i
In the Linux kernel, the following vulnerability has been resolved:
amt: Don't support cross-netns setup.
When a lower device is unregistered, amt_device_event() tries
to unregister its upper AMT device, but it has two problems.
1. amt_lookup_upper_dev() looks up an upper device in the
lower device's netns only
2. amt_device_event() unregisters a single upper device only
If AMT device is created on a lower device in another netns,
removing the lower device triggers the splat below and gets
stuck until all upper devices are removed. [0]
The cross-netns setup seems unintentional considering 1. and
the following points:
* amt_
apparmor: fix unconfined user namespace restriction forced stack
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix unconfined user namespace restriction forced stack
If a task is already confined by a stack the unprivileged transition
restriction on unconfined is not correctly, applied. This results in
an escape if two transitions through an unconfined profile can be
executed.
Fix this by pushing the check into the per profile label build. The
check will always be done against unconfined and result in a stack of
just the unconfined component when necessary.