Linux: >> Linux Kernel >> 6.1.112 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
xfs: delete attr leaf freemap entries when empty
Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size
underflow"), Brian Foster observed that it's possible for a small
freemap at the end of the end of the xattr entries array to experience
a size underflow when subtracting the space consumed by an expansion of
the entries array. There are only three freemap entries, which means
that it is not a complete index of all free space in the leaf block.
This code can leave behind a zero-length freemap entry with a nonzero
base. Subsequent setxattr operations can increase the base up to the
point that it overlaps with another freemap entry. This isn't in and of
itself a problem because the code in _leaf_add that finds free space
ignores any freemap entry with zero size.
However, there's another bug in the freemap update code in _leaf_add,
which is that it fails to update a freemap entry that begins midway
through the xattr entry that was just appended to the array. That can
result in the freemap containing two entries with the same base but
different sizes (0 for the "pushed-up" entry, nonzero for the entry
that's actually tracking free space). A subsequent _leaf_add can then
allocate xattr namevalue entries on top of the entries array, leading to
data loss. But fixing that is for later.
For now, eliminate the possibility of confusion by zeroing out the base
of any freemap entry that has zero size. Because the freemap is not
intended to be a complete index of free space, a subsequent failure to
find any free space for a new xattr will trigger block compaction, which
regenerates the freemap.
It looks like this bug has been in the codebase for quite a long time.
CVSS Score
8.8
EPSS Score
0.001
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_tcpmss: check remaining length before reading optlen
Quoting reporter:
In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads
op[i+1] directly without validating the remaining option length.
If the last byte of the option field is not EOL/NOP (0/1), the code attempts
to index op[i+1]. In the case where i + 1 == optlen, this causes an
out-of-bounds read, accessing memory past the optlen boundary
(either reading beyond the stack buffer _opt or the
following payload).
CVSS Score
8.2
EPSS Score
0.001
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode
kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls
netif_stop_queue() and netif_wake_queue(). These are TX queue flow
control functions unrelated to RX multicast configuration.
The premature netif_wake_queue() can re-enable TX while tx_urb is still
in-flight, leading to a double usb_submit_urb() on the same URB:
kaweth_start_xmit() {
netif_stop_queue();
usb_submit_urb(kaweth->tx_urb);
}
kaweth_set_rx_mode() {
netif_stop_queue();
netif_wake_queue(); // wakes TX queue before URB is done
}
kaweth_start_xmit() {
netif_stop_queue();
usb_submit_urb(kaweth->tx_urb); // URB submitted while active
}
This triggers the WARN in usb_submit_urb():
"URB submitted while active"
This is a similar class of bug fixed in rtl8150 by
- commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").
Also kaweth_set_rx_mode() is already functionally broken, the
real set_rx_mode action is performed by kaweth_async_set_rx_mode(),
which in turn is not a no-op only at ndo_open() time.
CVSS Score
7.8
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
media: ccs: Avoid possible division by zero
Calculating maximum M for scaler configuration involves dividing by
MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably
non-zero, the driver was missing the check it in fact was. Fix this.
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix a resource leak in cx25821_dev_setup()
Add release_mem_region() if ioremap() fails to release the memory
region obtained by cx25821_get_resources().
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix reflink preserve cleanup issue
commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")
doesn't handle all cases and the cleanup job for preserved xattr entries
still has bug:
- the 'last' pointer should be shifted by one unit after cleanup
an array entry.
- current code logic doesn't cleanup the first entry when xh_count is 1.
Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Move vbus draw to workqueue context
Currently dwc3_gadget_vbus_draw() can be called from atomic
context, which in turn invokes power-supply-core APIs. And
some these PMIC APIs have operations that may sleep, leading
to kernel panic.
Fix this by moving the vbus_draw into a workqueue context.
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
EFI/CPER: don't dump the entire memory region
The current logic at cper_print_fw_err() doesn't check if the
error record length is big enough to handle offset. On a bad firmware,
if the ofset is above the actual record, length -= offset will
underflow, making it dump the entire memory.
The end result can be:
- the logic taking a lot of time dumping large regions of memory;
- data disclosure due to the memory dumps;
- an OOPS, if it tries to dump an unmapped memory region.
Fix it by checking if the section length is too small before doing
a hex dump.
[ rjw: Subject tweaks ]
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fix 22000 series SMEM parsing
If the firmware were to report three LMACs (which doesn't
exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is
an overrun of the array. Reject such and use IWL_FW_CHECK
instead of WARN_ON in this function.
CVSS Score
8.8
EPSS Score
0.0
Published
2026-05-06
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: xscale: Check for PTP support properly
In ixp4xx_get_ts_info() ixp46x_ptp_find() is called
unconditionally despite this feature only existing on
ixp46x, leading to the following splat from tcpdump:
root@OpenWrt:~# tcpdump -vv -X -i eth0
(...)
Unable to handle kernel NULL pointer dereference at virtual address
00000238 when read
(...)
Call trace:
ptp_clock_index from ixp46x_ptp_find+0x1c/0x38
ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64
ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108
__ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648
__dev_ethtool from dev_ethtool+0x160/0x234
dev_ethtool from dev_ioctl+0x2cc/0x460
dev_ioctl from sock_ioctl+0x1ec/0x524
sock_ioctl from sys_ioctl+0x51c/0xa94
sys_ioctl from ret_fast_syscall+0x0/0x44
(...)
Segmentation fault
Check for ixp46x in ixp46x_ptp_find() before trying to set up
PTP to avoid this.
To avoid altering the returned error code from ixp4xx_hwtstamp_set()
which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP
from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter
the error code. The helper function ixp46x_ptp_find() helper
returns -ENODEV.
CVSS Score
5.5
EPSS Score
0.0
Published
2026-05-06