| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix readdir position truncation on 32-bit kernels
In ocfs2_dir_foreach_blk_el(), the directory cookie position is
rebuilt with
ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask
~(sb->s_blocksize - 1)
is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size). In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000. The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB.
When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.
This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
for all non-inline directories, so a directory large enough to cross
4 GiB reaches it.
This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat, and the
fix mirrors the equivalent ext4 fix in this series. Cast the operand
to loff_t so the mask is 64-bit before the AND:
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
64-bit kernels are unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: reject a read that transferred too few bytes
nvme_tcp_recv_data() completes a request once the current C2HData PDU
has been consumed. Nothing compares the total bytes received against
the length the command asked for: struct nvme_tcp_request has no
receive-side counter, queue->data_remaining is per queue, and
blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally
with no residual concept anywhere above.
A controller can therefore answer a 4096-byte read with 512 bytes and
have it reported as a complete read; user space then gets 4096 bytes of
which 3584 are whatever was already in the page. I reproduced that with
a test target.
Count the bytes received and refuse to complete a successful read whose
count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in
nvme_tcp_process_nvme_cqe(). The success test shifts req->status right
by one, because the driver keeps the wire value there and shifts it on
completion, so the check must see what the completion path will see.
Only REQ_OP_READ is checked, because there the length comes from the
sectors the request covers; a passthrough command is built by its
submitter, which picks both command and buffer, so the kernel has
nothing to compare against. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: fix stream->outcnt underflow on duplicate RECONF responses
A cached RECONF chunk may contain more than one request parameter. A
duplicate response can therefore find and process the same ADD_OUT request
again while another parameter is still outstanding, rolling back outcnt
twice and possibly underflowing it.
Track outstanding request types as bits and clear each bit after its first
response. Later responses for the same request are then ignored. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: qcom_battmgr: terminate the strings from firmware
The qcom_battmgr_sc8280xp_strcpy() takes a Pascal-style string when the
firmware sends one. Otherwise it copies all BATTMGR_STRING_LEN bytes and
leaves the destination without a terminator.
Those destinations are model_number, serial_number and oem_info, each
BATTMGR_STRING_LEN and declared next to each other. They go out to user
space as val->strval, which power_supply_format_property() prints with
"%s", so a firmware string that fills the whole field makes that read run
into the following members.
Use strscpy() so the copy always terminates, the way the SM8350 path
already does for the same field. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate level in perf mask ioctls
isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask() use the
user-provided level as an index into perf_levels[] via
_read_pp_level_info() and _read_bf_level_info(), but neither helper
validates it first.
The adjacent level-info helpers reject levels above max_level before
reading the same per-level register block. Add the same bounds checks to
the mask helpers, and reject disabled SST-PP levels in
isst_if_get_perf_level_mask() to match isst_if_get_perf_level_info().
This prevents out-of-bounds reads from the per-level offset table on
invalid ioctl input. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store()
sk_store() and kek_store() strip a trailing newline from the sysfs
write before allocating the key buffer:
length = count;
if (buf[length - 1] == '\n')
length--;
bioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL);
but then pass the original "count" (not "length") as the copy size to
hp_wmi_perform_query(), which memcpy()s that many bytes out of the
"length"-sized allocation, reading one byte past it whenever the write
ends in a newline, the normal case for a shell "echo" into sysfs.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg]
Read of size 28 at addr ffff88813c8e2b80 by task python3/16022
...
sk_store+0xa7/0x240 [hp_bioscfg]
kernfs_fop_write_iter+0x3e1/0x5d0
...
The buggy address is located 0 bytes inside of
allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b)
Reproduced identically for kek_store, and at multiple write sizes
(28, 57, 201 bytes), each time reading exactly one byte past a
kmemdup() allocation one byte smaller than the write.
Fix by passing "length" instead of "count" to hp_wmi_perform_query()
in both functions. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix heap OOB read on empty password write
validate_password_input() computes length = strlen(buf) and then
checks buf[length - 1] to strip a trailing newline, without checking
that length is nonzero first. Writing an empty string (a bare '\n')
to current_password or new_password gives length == 0, and
buf[length - 1] reads buf[-1], one byte before the heap allocation
holding the copied input.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
Read of size 1 at addr ffff88811bd8da9f by task sh/13740
...
store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
current_password_store+0x14/0x20 [hp_bioscfg]
...
The buggy address is located 23 bytes to the right of
allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88)
Reproduced identically via new_password_store. Execution continues
past the bad read (the garbage byte only affects whether "length" is
decremented by one), so the write completes and returns success; this
is a pure information read past the buffer, not a crash, but it is
still an out-of-bounds access KASAN correctly flags.
Fix by only checking buf[length - 1] when length is nonzero. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer()
hp_get_string_from_buffer() clamps the converted string length against
the destination buffer size with "size > dst_size", so when the
converted length is exactly equal to dst_size, conv_dst_size is left
at dst_size and the unconditional NUL terminator write
dst[conv_dst_size] = 0;
lands one byte past the destination buffer. This is the same shape of
bug as the previously fixed off-by-one in hp_convert_hexstr_to_str():
the buffer is sized correctly for the content, but the terminator
write is never checked against that size.
Fix by changing the comparison to ">=" so conv_dst_size is always left
with room for the terminator.
All fixed-size destinations that reach this function (path[512],
current_value[512], current_password/current_value[64], and the
per-entry buffers in encodings[][512] and prerequisites[][512]) are
affected. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: pass validated element count to package parsers
The per-type package parsers are handed the wrong element count.
hp_init_bios_package_attribute() validates obj->package.count and then
calls one of the five hp_populate_*_package_data() wrappers (string,
integer, enumeration, ordered list, password). Each wrapper forwards a
count to its hp_populate_*_elements_from_package() parser, but instead
of forwarding the validated obj->package.count it derives the count
from elements[0]. elements[0] is the NAME field and is always an
ACPI_TYPE_STRING, so reading ->package.count from it in fact reads
->string.length through the union acpi_object. The parsers thus bound
themselves against the length of the name string rather than against
the real number of elements in the package.
This is safe today because hp_init_bios_package_attribute() refuses any
package that has fewer than the type's element count, so a parser only
ever runs on a full package and never reads past it regardless of the
bogus bound.
An upcoming change relaxes that check to accept shorter packages. Once
a parser can receive fewer elements than its per-type count, a bound
taken from the name length no longer reflects the array size, and the
"elem < count" loop conditions and "elem + n >= count" sub-loop guards
read past the end of elements[] - an out-of-bounds heap read.
Forward the validated obj->package.count to every *_package_data()
wrapper so the parsers bound themselves against the real package size.
This does not change behaviour for the packages that enumerate
correctly today and is a prerequisite for accepting shorter packages
safely. |
| In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: Mark the connection down when bringing it up fails
Every failure path in tbnet_connected_work() undoes its own work and
returns without clearing login_sent, so the connection still looks
established. The next tbnet_tear_down() therefore takes its main branch
and repeats a teardown that already happened: it stops rings that are
already stopped, which is a dev_WARN() and fatal under panic_on_warn,
and it releases net->remote_transmit_path even on the HopID mismatch
path, where this connection never owned that id, silently freeing one
that someone else is still using.
Clear login_sent on those paths. That is enough for tbnet_tear_down() to
leave the unwound state alone, and login_received has to stay set: it
records that the peer has logged in and carries the transmit path it gave
us, which nothing on this side can make the peer send again. Two things
change beyond keeping the teardown out of the way: the logout request in
that block is no longer sent, and the peer's next login request now
re-queues our login work rather than connected_work, giving the
connection a fresh login instead of a retry on stale state. |
| In the Linux kernel, the following vulnerability has been resolved:
net: cap advertised IP tunnel headroom
IP tunnel devices derive their advertised needed_headroom from lower
output devices. A stack of user-created devices can make the derived
value larger than the 16-bit skb header offsets can represent. Once IP
output reserves it, skb head expansion can wrap those offsets.
The runtime transmit path already caps a growing needed_headroom at 512.
Apply the same cap when tunnel configuration publishes needed_headroom
derived from a lower output device.
Capping the advertised value is safe: IP tunnel transmit still expands
the skb when a packet needs more headroom. A nonsensical stacked
configuration can therefore incur an extra reallocation, but it cannot
publish an unbounded reservation to upper layers. |
| In the Linux kernel, the following vulnerability has been resolved:
seg6: reset IP6CB after IPv6 decapsulation
decap_and_validate() pulls the outer SRv6 headers and makes the inner
packet the skb network header. The IPv6 control block still contains
values collected while parsing the outer packet, including nhoff and
extension-header flags.
End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6
input path. An unprivileged user can reach End.DT6 from a user and net
namespace by installing a local SID and injecting an outer packet with
Hop-by-Hop and Destination Options headers followed by an SRH and a
minimal inner IPv6 packet.
The outer extension headers leave a large nhoff in IP6CB. After
decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the
inner packet and reads beyond the skb head. KASAN reports:
BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu
ip6_protocol_deliver_rcu+0x1118/0x1450
ip6_input_finish+0x11b/0x240
seg6_local_input_core+0xed/0x2e0
lwtunnel_input+0x1e9/0x4e0
ipv6_rthdr_rcv+0x525f/0x6c50
ip6_protocol_deliver_rcu+0xcb7/0x1450
Before clearing IP6CB for an inner IPv6 packet, save its incoming
interface index and L3 slave state. Restore both after the clear and set
nhoff to the inner IPv6 base-header nexthdr field.
Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can
replace skb_iif with the L3 master while IP6CB keeps the receiving
interface. Preserve IP6SKB_L3SLAVE for the same reason. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: bound the MIDI event length from the device
usb6fire_comm_receiver_handler() forwards a MIDI event using a length
byte the device supplies, with no bound and no check that the transfer
delivered that many bytes:
if (!urb->status) {
if (rt->receiver_buffer[0] == 0x10) /* midi in event */
if (midi_rt)
midi_rt->in_received(midi_rt,
rt->receiver_buffer + 2,
rt->receiver_buffer[1]);
}
receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so
only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the
device chooses, so a device that answers with 0x10 and a length of 0xFF
makes snd_rawmidi_receive() read 255 bytes starting two bytes into a
64-byte object. The bytes past the buffer are handed to userspace
through the rawmidi read path.
urb->actual_length is not consulted either, so a short transfer leaves
both the type byte and the length byte at their previous values and the
handler acts on stale data.
The receiver URB is submitted from usb6fire_comm_init() at probe, so the
read happens on plug with no user action; forwarding to userspace also
needs a MIDI input substream open, since usb6fire_midi_in_received()
only calls snd_rawmidi_receive() when rt->in is set.
KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device:
BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive
Read of size 255 at addr ffff000009f64682 by task bash/183
__asan_memcpy
snd_rawmidi_receive
usb6fire_midi_in_received [snd_usb_6fire]
usb6fire_comm_receiver_handler [snd_usb_6fire]
Allocated by task 11:
usb6fire_comm_init [snd_usb_6fire]
usb6fire_chip_probe [snd_usb_6fire]
The buggy address is located 2 bytes inside of
allocated 64-byte region [ffff000009f64680, ffff000009f646c0)
Reject the event when the length exceeds the bytes that follow the
header, and require the transfer to have delivered the header plus that
many bytes. The receiver URB is submitted with a 64-byte
transfer_buffer_length, so a genuine device cannot deliver an event
longer than those 62 bytes and nothing valid is dropped.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: aloop: Check card index validity at probe
aloop driver blindly trusts that the given devptr->id value is within
the proper card index range at probe. It's OK for the devices the
driver itself creates at the module probe time, but if the device is
bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: mpu401: Check card index validity at probe
mpu401 driver blindly trusts that the given devptr->id value is within
the proper card index range at probe. It's OK for the devices the
driver itself creates at the module probe time, but if the device is
bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: portman2x4: Check card index validity at probe
Although portman2x4 driver has a check of the given devptr->id value,
it doesn't check for a negative id, which is often given as "none" or
such value when bound via sysfs. This may lead to OOB access for
index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: virmidi: Check card index validity at probe
virmidi driver blindly trusts that the given devptr->id value is
within the proper card index range at probe. It's OK for the devices
the driver itself creates at the module probe time, but if the device
is bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: validate default EEPROM firmware size
The default EEPROM firmware is parsed and copied as a full EEPROM
without checking its length. A truncated file can make the driver
read beyond the firmware buffer during variant validation or the
fallback copy.
Reject files shorter than MT7996_EEPROM_SIZE before parsing or
copying the firmware. |
| In the Linux kernel, the following vulnerability has been resolved:
w1: ds28e17: reject an oversize length on an I2C block read
w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire
to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the
device. The downstream slave puts a length byte in buf[0]. The driver
then reads that many bytes into buf[1] with w1_f19_i2c_read().
buf[0] is controlled by the device and can be 0 to 255.
w1_f19_i2c_read() only rejects a zero count. The caller buffer is
I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read
run past it, up to about 222 bytes out of bounds.
The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That
check runs after master_xfer returns. By then the write is already
done. i2c-algo-bit rejects an oversize length before it copies, and
returns -EPROTO.
Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the
same way i2c-algo-bit does. |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: use pskb_network_may_pull() for transmit path header pulls
In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was
being called to verify the availability of network layer headers (ARP, IPv6/ND,
IP/IPv6 MDB keys).
However, during transmit skb->data points to the MAC header, so skb_network_offset(skb)
is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data
rather than skb_network_offset(skb) + len, which can leave part of the network header
in non-linear frags.
Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly
account for the MAC header offset. |
