🚨 CVE-2026-74701
In the Linux kernel, the following vulnerability has been resolved:
net/openvswitch: check Ethernet header length in key_extract()
When a packet arrives on an ARPHRD_NONE device (e.g. TUN),
ovs_flow_key_extract() trusts the user-provided skb->protocol field: if
it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and
key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes
of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes
for MAC addresses and parse_ethertype() pulls 2 more, either of which
triggers a kernel BUG in __skb_pull() when the linear area is too small.
kernel BUG at include/linux/skbuff.h:2848!
RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933
ovs_flow_key_extract+0x419/0xa70
ovs_vport_receive+0x222/0x390
netdev_frame_hook+0x3e0/0x630
tun_get_user+0x2d0c/0x38e0
Fixed by calling check_header() in key_extract() before accessing the
Ethernet header.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/openvswitch: check Ethernet header length in key_extract()
When a packet arrives on an ARPHRD_NONE device (e.g. TUN),
ovs_flow_key_extract() trusts the user-provided skb->protocol field: if
it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and
key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes
of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes
for MAC addresses and parse_ethertype() pulls 2 more, either of which
triggers a kernel BUG in __skb_pull() when the linear area is too small.
kernel BUG at include/linux/skbuff.h:2848!
RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933
ovs_flow_key_extract+0x419/0xa70
ovs_vport_receive+0x222/0x390
netdev_frame_hook+0x3e0/0x630
tun_get_user+0x2d0c/0x38e0
Fixed by calling check_header() in key_extract() before accessing the
Ethernet header.
🎖@cveNotify
🚨 CVE-2026-74702
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: reject feature changes after endpoint
vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates
each command's protection scatterlist array (prot_sgl) according to the
acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt
when VHOST_SET_FEATURES changes that bit later.
Although virtio feature bits must not change after feature negotiation,
vhost_scsi_set_features() currently accepts such a request after the
endpoint is active and updates acked_features. Enabling T10-PI after
endpoint setup therefore leaves prot_sgl NULL while the I/O path follows
the new feature bit.
For a 129-page protection payload, vhost_scsi_mapal() passes the missing
first chunk to sg_alloc_table_chained():
sg_alloc_table_chained(table, 129, first_chunk=NULL,
nents_first_chunk=inline_sg_cnt)
sg_pool_index() then hits:
BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */
The kernel reported the following call trace and register state:
Call Trace:
<TASK>
? __sg_alloc_table+0x1d8/0x250
? __pfx_vhost_run_work_list+0x10/0x10 [vhost]
sg_alloc_table_chained+0x59/0xf0
? __pfx_sg_pool_alloc+0x10/0x10
? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]
vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]
? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]
vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]
vhost_run_work_list+0x8e/0xd0 [vhost]
vhost_task_fn+0xe1/0x210
ret_from_fork+0x348/0x540
</TASK>
RIP: 0010:0x4
CR2 = 0x4
RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202
RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081
VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only
exception.
Reject changes to any feature other than VHOST_F_LOG_ALL while the
endpoint is active. This preserves the existing runtime log toggle while
preventing feature-dependent command resources and data-path state from
becoming inconsistent. Userspace must clear the endpoint before changing
any other negotiated feature and set the endpoint up again afterward.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: reject feature changes after endpoint
vhost_scsi_setup_vq_cmds() runs from VHOST_SCSI_SET_ENDPOINT and allocates
each command's protection scatterlist array (prot_sgl) according to the
acknowledged VIRTIO_SCSI_F_T10_PI bit. The command pools are not rebuilt
when VHOST_SET_FEATURES changes that bit later.
Although virtio feature bits must not change after feature negotiation,
vhost_scsi_set_features() currently accepts such a request after the
endpoint is active and updates acked_features. Enabling T10-PI after
endpoint setup therefore leaves prot_sgl NULL while the I/O path follows
the new feature bit.
For a 129-page protection payload, vhost_scsi_mapal() passes the missing
first chunk to sg_alloc_table_chained():
sg_alloc_table_chained(table, 129, first_chunk=NULL,
nents_first_chunk=inline_sg_cnt)
sg_pool_index() then hits:
BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */
The kernel reported the following call trace and register state:
Call Trace:
<TASK>
? __sg_alloc_table+0x1d8/0x250
? __pfx_vhost_run_work_list+0x10/0x10 [vhost]
sg_alloc_table_chained+0x59/0xf0
? __pfx_sg_pool_alloc+0x10/0x10
? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]
vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]
? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]
vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]
vhost_run_work_list+0x8e/0xd0 [vhost]
vhost_task_fn+0xe1/0x210
ret_from_fork+0x348/0x540
</TASK>
RIP: 0010:0x4
CR2 = 0x4
RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202
RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081
VHOST_F_LOG_ALL is a vhost-specific runtime feature and remains the only
exception.
Reject changes to any feature other than VHOST_F_LOG_ALL while the
endpoint is active. This preserves the existing runtime log toggle while
preventing feature-dependent command resources and data-path state from
becoming inconsistent. Userspace must clear the endpoint before changing
any other negotiated feature and set the endpoint up again afterward.
🎖@cveNotify
🚨 CVE-2026-74703
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Validate T10 PI scatterlist counts
When T10 PI is negotiated, vhost-scsi splits protection bytes from
the data iterator before mapping the request scatterlists. A malformed
request can claim protection bytes that cover or exceed the full payload
length. The former leaves no data bytes to map, while the latter
underflows exp_data_len before advancing the iterator. Both cases can let
a zero data SGL count reach sg_alloc_table_chained(), which triggers
BUG_ON(!nents).
Reject protection lengths that cover or exceed the payload before
subtracting prot_bytes and advancing the iterator. Also propagate
negative errors from the protection SGL calculation before calling the
allocator, matching the data SGL path.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Validate T10 PI scatterlist counts
When T10 PI is negotiated, vhost-scsi splits protection bytes from
the data iterator before mapping the request scatterlists. A malformed
request can claim protection bytes that cover or exceed the full payload
length. The former leaves no data bytes to map, while the latter
underflows exp_data_len before advancing the iterator. Both cases can let
a zero data SGL count reach sg_alloc_table_chained(), which triggers
BUG_ON(!nents).
Reject protection lengths that cover or exceed the payload before
subtracting prot_bytes and advancing the iterator. Also propagate
negative errors from the protection SGL calculation before calling the
allocator, matching the data SGL path.
🎖@cveNotify
🚨 CVE-2026-74704
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter
The sch_cake ACK filter parses packets to find the TCP header and filter
duplicated ACKs if the flow is backlogged. The parsing code contains a
WARN_ON(1) which can be triggered by a malformed IP header in certain
cases. Depending on the system configuration, this leads either to
either spamming dmesg with warnings, or a panic if panic_on_warn is set.
The code already correctly skips the offending packet in the branch that
triggers the warning, so the WARN_ON itself doesn't really serve any
purpose. So just drop it altogether to avoid the inconvenient side
effects.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter
The sch_cake ACK filter parses packets to find the TCP header and filter
duplicated ACKs if the flow is backlogged. The parsing code contains a
WARN_ON(1) which can be triggered by a malformed IP header in certain
cases. Depending on the system configuration, this leads either to
either spamming dmesg with warnings, or a panic if panic_on_warn is set.
The code already correctly skips the offending packet in the branch that
triggers the warning, so the WARN_ON itself doesn't really serve any
purpose. So just drop it altogether to avoid the inconvenient side
effects.
🎖@cveNotify
🚨 CVE-2026-74705
In the Linux kernel, the following vulnerability has been resolved:
udp: fix potential use-after-free in tunnel segmentation
__skb_udp_tunnel_segment() gets the UDP header before ensuring the
tunnel header is in the skb head. If the pull reallocates skb->head,
the saved UDP header pointer is no longer valid.
Get the UDP header after the pull to avoid a potential use-after-free.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
udp: fix potential use-after-free in tunnel segmentation
__skb_udp_tunnel_segment() gets the UDP header before ensuring the
tunnel header is in the skb head. If the pull reallocates skb->head,
the saved UDP header pointer is no longer valid.
Get the UDP header after the pull to avoid a potential use-after-free.
🎖@cveNotify
🚨 CVE-2026-74706
In the Linux kernel, the following vulnerability has been resolved:
bnge: Fix NULL pointer dereference in aux device release
If allocation of auxr_dev fails during auxiliary device setup, the error
path calls auxiliary_device_uninit(), which eventually invokes
bnge_aux_dev_release().
The release callback unconditionally dereferences aux_priv->auxr_dev->pdev
to retrieve the parent bnge_dev. Since auxr_dev has not yet been allocated
on this failure path, the dereference results in a NULL pointer exception
Retrieve the parent bnge_dev from the auxiliary device's parent instead of
auxr_dev, and free auxr_dev only when it was successfully allocated. This
allows the release callback to correctly clean up partially initialized
auxiliary devices.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bnge: Fix NULL pointer dereference in aux device release
If allocation of auxr_dev fails during auxiliary device setup, the error
path calls auxiliary_device_uninit(), which eventually invokes
bnge_aux_dev_release().
The release callback unconditionally dereferences aux_priv->auxr_dev->pdev
to retrieve the parent bnge_dev. Since auxr_dev has not yet been allocated
on this failure path, the dereference results in a NULL pointer exception
Retrieve the parent bnge_dev from the auxiliary device's parent instead of
auxr_dev, and free auxr_dev only when it was successfully allocated. This
allows the release callback to correctly clean up partially initialized
auxiliary devices.
🎖@cveNotify
🚨 CVE-2026-74707
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate metadata when processing requests
The zero-copy path validates TX metadata while obtaining the descriptor
context, then reads it again later when preparing the hardware request.
User space can change the metadata between those operations and bypass the
original validation.
Validate the metadata in xsk_tx_metadata_request() and use the resulting
flags snapshot for every feature check. Read request fields once so all
zero-copy drivers process only values observed after successful
validation.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate metadata when processing requests
The zero-copy path validates TX metadata while obtaining the descriptor
context, then reads it again later when preparing the hardware request.
User space can change the metadata between those operations and bypass the
original validation.
Validate the metadata in xsk_tx_metadata_request() and use the resulting
flags snapshot for every feature check. Read request fields once so all
zero-copy drivers process only values observed after successful
validation.
🎖@cveNotify
🚨 CVE-2026-74709
In the Linux kernel, the following vulnerability has been resolved:
xsk: clear metadata pointer when no timestamp is requested
User space can change metadata flags after request processing. Rereading
them during completion can therefore make the kernel write a timestamp
that was not requested when the packet was submitted.
Clear the metadata pointer during request processing unless timestamp
completion is requested. Completion handling can then use the pointer
itself instead of rereading the flags.
On the mlx5 multi-packet WQE path metadata is evaluated per batch:
xsk_tx_metadata_request() runs only for the descriptor that starts a
session, just like the checksum offload that is applied once through the
shared WQE. Only that descriptor's pointer is reset, so completion
handling can record a timestamp for the other descriptors of the session
regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays
inside the metadata area; the single-WQE, other zero-copy, and generic
paths reset the pointer per descriptor and are unaffected.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xsk: clear metadata pointer when no timestamp is requested
User space can change metadata flags after request processing. Rereading
them during completion can therefore make the kernel write a timestamp
that was not requested when the packet was submitted.
Clear the metadata pointer during request processing unless timestamp
completion is requested. Completion handling can then use the pointer
itself instead of rereading the flags.
On the mlx5 multi-packet WQE path metadata is evaluated per batch:
xsk_tx_metadata_request() runs only for the descriptor that starts a
session, just like the checksum offload that is applied once through the
shared WQE. Only that descriptor's pointer is reset, so completion
handling can record a timestamp for the other descriptors of the session
regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays
inside the metadata area; the single-WQE, other zero-copy, and generic
paths reset the pointer per descriptor and are unaffected.
🎖@cveNotify
🚨 CVE-2026-74710
In the Linux kernel, the following vulnerability has been resolved:
xsk: require at least 16 bytes of TX metadata
AF_XDP accepts a TX metadata length as small as eight bytes, but every
supported request needs the flags plus at least one eight-byte request
field. Such short metadata also lets the kernel read beyond the registered
area.
Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve
compatibility with applications that do not use launch-time metadata.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xsk: require at least 16 bytes of TX metadata
AF_XDP accepts a TX metadata length as small as eight bytes, but every
supported request needs the flags plus at least one eight-byte request
field. Such short metadata also lets the kernel read beyond the registered
area.
Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve
compatibility with applications that do not use launch-time metadata.
🎖@cveNotify
🚨 CVE-2026-74711
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus) Fix type confusion in notification logic
Sashiko reports:
At the start of the loop in pmbus_notify(), the code unconditionally casts
every attribute to a struct sensor_device_attribute:
drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() {
for (i = 0; i < data->num_attributes; i++) {
struct device_attribute *da = to_dev_attr(data->group.attrs[i]);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
int index = attr->index;
...
}
However, data->group.attrs can contain other types like struct
pmbus_samples_reg or struct pmbus_sensor, which only embed a base
struct device_attribute.
If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting
it to struct sensor_device_attribute and reading the index field appears
to access memory past the end of the allocation, which might trigger a
slab-out-of-bounds read.
Additionally, if da is a struct pmbus_sensor, casting it causes the index
field to overlap with the page, phase, and reg fields. Could this produce
a garbage mask on little-endian systems that spuriously matches the target
reg, page, and flags during an alert?
Fix the problem by using struct sensor_device_attr in struct pmbus_sensor
and struct pmbus_label. Since those attributes never trigger a
notification, set the value of attr->index to -1 for them. Use this value
to distinguish from boolean attributes which _can_ trigger a notification
and use the index field to encode mask, page, and register values.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus) Fix type confusion in notification logic
Sashiko reports:
At the start of the loop in pmbus_notify(), the code unconditionally casts
every attribute to a struct sensor_device_attribute:
drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() {
for (i = 0; i < data->num_attributes; i++) {
struct device_attribute *da = to_dev_attr(data->group.attrs[i]);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
int index = attr->index;
...
}
However, data->group.attrs can contain other types like struct
pmbus_samples_reg or struct pmbus_sensor, which only embed a base
struct device_attribute.
If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting
it to struct sensor_device_attribute and reading the index field appears
to access memory past the end of the allocation, which might trigger a
slab-out-of-bounds read.
Additionally, if da is a struct pmbus_sensor, casting it causes the index
field to overlap with the page, phase, and reg fields. Could this produce
a garbage mask on little-endian systems that spuriously matches the target
reg, page, and flags during an alert?
Fix the problem by using struct sensor_device_attr in struct pmbus_sensor
and struct pmbus_label. Since those attributes never trigger a
notification, set the value of attr->index to -1 for them. Use this value
to distinguish from boolean attributes which _can_ trigger a notification
and use the index field to encode mask, page, and register values.
🎖@cveNotify
🚨 CVE-2026-74712
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: Fix buffer length in create_direct_keys()
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Properly calculate the input size to match the pointer and allocation size.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: Fix buffer length in create_direct_keys()
We have seen in our CI the following KASAN message:
BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core]
Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764
[...]
[<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core]
[<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core]
[<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa]
[<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa]
[...]
The buggy address is located 4128 bytes inside of
allocated 4384-byte region [0000000176794000, 0000000176795120)
So in essence we read 16 bytes beyond 4384-byte allocation.
create_direct_keys calculates the pointer and length for in and out
buffers.
The size calculation for in includes the entire structure
size (out + in + mtt[]) but the pointer passed to cmd_exec points only
to the 'in' field, skipping the 'out' field.
This causes mlx5_copy_to_msg() to read beyond the allocated buffer
by sizeof(out) bytes when copying command data.
Properly calculate the input size to match the pointer and allocation size.
🎖@cveNotify
🚨 CVE-2026-74713
In the Linux kernel, the following vulnerability has been resolved:
vhost_iotlb: bound map allocation in add_range
vhost_iotlb_add_range_ctx() only retires an old entry when the table
has a non-zero limit, has exactly reached that limit and has
VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating
entries after reaching their configured limit.
Existing vhost devices allocate their IOTLB with max_iotlb_entries from
vhost.c, which defaults to 2048 and is tunable by module parameter. Use
the caller-provided limit at the allocation point instead of adding a
separate default in the common IOTLB helper, and reject non-positive
values in vhost paths that can report an error.
Other vhost IOTLB users should not create zero-limit tables when entries
can be populated from userspace or guest-controlled requests. Add
caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and
vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require
at least two entries for vdpa_sim and mlx5 vDPA paths that install
full-range mappings, since those mappings are split into two IOTLB
entries.
Handle full-range mappings in the common helper by checking that the
IOTLB can hold both split entries before inserting the first half. This
avoids returning an error after leaving a half mapping behind.
When the table is full, keep the existing retire behavior for retiring
tables and return -ENOSPC for non-retiring tables. Reuse the retired map
node instead of freeing it and allocating a replacement, so a stream of
IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table
has reached its limit. If a zero-limit IOTLB still reaches the common
helper, treat it as a configuration error and return -EINVAL.
I found this bug myself, though the patch was written with AI assistance.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
vhost_iotlb: bound map allocation in add_range
vhost_iotlb_add_range_ctx() only retires an old entry when the table
has a non-zero limit, has exactly reached that limit and has
VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating
entries after reaching their configured limit.
Existing vhost devices allocate their IOTLB with max_iotlb_entries from
vhost.c, which defaults to 2048 and is tunable by module parameter. Use
the caller-provided limit at the allocation point instead of adding a
separate default in the common IOTLB helper, and reject non-positive
values in vhost paths that can report an error.
Other vhost IOTLB users should not create zero-limit tables when entries
can be populated from userspace or guest-controlled requests. Add
caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and
vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require
at least two entries for vdpa_sim and mlx5 vDPA paths that install
full-range mappings, since those mappings are split into two IOTLB
entries.
Handle full-range mappings in the common helper by checking that the
IOTLB can hold both split entries before inserting the first half. This
avoids returning an error after leaving a half mapping behind.
When the table is full, keep the existing retire behavior for retiring
tables and return -ENOSPC for non-retiring tables. Reuse the retired map
node instead of freeing it and allocating a replacement, so a stream of
IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table
has reached its limit. If a zero-limit IOTLB still reaches the common
helper, treat it as a configuration error and return -EINVAL.
I found this bug myself, though the patch was written with AI assistance.
🎖@cveNotify
🚨 CVE-2026-74714
In the Linux kernel, the following vulnerability has been resolved:
bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto
the ehash chain, drops the bucket lock, and only afterwards sets
rsk_refcnt to 3.
Lockless readers such as __inet_lookup_established() handle this with
refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain
sock_hold() while holding the bucket lock, on the assumption that the
lock guarantees sk_refcnt > 0. That assumption does not hold for
request_sock:
CPU 0 CPU 1
----- -----
tcp_conn_request()
reqsk_queue_hash_req()
inet_ehash_insert(req)
spin_lock(bucket)
__sk_nulls_add_node_rcu(req) // rsk_refcnt == 0
spin_unlock(bucket)
bpf_iter_tcp_established_batch()
spin_lock(bucket)
sock_hold(req) <-- addition on 0
spin_unlock(bucket)
refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value
which surfaces as:
refcount_t: addition on 0; use-after-free.
WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1
Call Trace:
bpf_iter_tcp_established_batch+0x14e/0x170
bpf_iter_tcp_batch+0x53/0x200
bpf_iter_tcp_seq_next+0x27/0x70
bpf_seq_read+0x107/0x410
vfs_read+0xb9/0x380
The iterator's stolen reference is lost when the publishing CPU's
refcount_set() overwrites the count, leaving the socket one reference
short. When the last legitimate owner drops its reference the reqsk is
freed while still reachable, leading to use-after-free.
This reproduces in seconds with tcp_syncookies=0, a handful of threads
doing connect()/close() to a local listener while others read an
iter/tcp link in a tight loop.
Use refcount_inc_not_zero() and skip the socket on failure. A skipped
socket is still part of the bucket, so keep counting it in expected.
The reallocations are sized from expected, and a request sock whose
refcount gets published while the lock is held across the last realloc
must already have room.
A skipped socket is counted in expected but never batched, so end_sk
can be short of expected on a batch that is actually complete. Decide
completeness by whether the walk left any socket behind instead. The
WARN after the locked realloc checks the same, replacing an
end_sk == expected check that could not hold on that path since
commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always
contains a full bucket snapshot").
If every matching socket in a bucket is mid-init (refcount 0), end_sk
stays 0. Advance to the next bucket rather than returning a batch entry
that was never filled this round.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto
the ehash chain, drops the bucket lock, and only afterwards sets
rsk_refcnt to 3.
Lockless readers such as __inet_lookup_established() handle this with
refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain
sock_hold() while holding the bucket lock, on the assumption that the
lock guarantees sk_refcnt > 0. That assumption does not hold for
request_sock:
CPU 0 CPU 1
----- -----
tcp_conn_request()
reqsk_queue_hash_req()
inet_ehash_insert(req)
spin_lock(bucket)
__sk_nulls_add_node_rcu(req) // rsk_refcnt == 0
spin_unlock(bucket)
bpf_iter_tcp_established_batch()
spin_lock(bucket)
sock_hold(req) <-- addition on 0
spin_unlock(bucket)
refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value
which surfaces as:
refcount_t: addition on 0; use-after-free.
WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1
Call Trace:
bpf_iter_tcp_established_batch+0x14e/0x170
bpf_iter_tcp_batch+0x53/0x200
bpf_iter_tcp_seq_next+0x27/0x70
bpf_seq_read+0x107/0x410
vfs_read+0xb9/0x380
The iterator's stolen reference is lost when the publishing CPU's
refcount_set() overwrites the count, leaving the socket one reference
short. When the last legitimate owner drops its reference the reqsk is
freed while still reachable, leading to use-after-free.
This reproduces in seconds with tcp_syncookies=0, a handful of threads
doing connect()/close() to a local listener while others read an
iter/tcp link in a tight loop.
Use refcount_inc_not_zero() and skip the socket on failure. A skipped
socket is still part of the bucket, so keep counting it in expected.
The reallocations are sized from expected, and a request sock whose
refcount gets published while the lock is held across the last realloc
must already have room.
A skipped socket is counted in expected but never batched, so end_sk
can be short of expected on a batch that is actually complete. Decide
completeness by whether the walk left any socket behind instead. The
WARN after the locked realloc checks the same, replacing an
end_sk == expected check that could not hold on that path since
commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always
contains a full bucket snapshot").
If every matching socket in a bucket is mid-init (refcount 0), end_sk
stays 0. Advance to the next bucket rather than returning a batch entry
that was never filled this round.
🎖@cveNotify
🚨 CVE-2026-74715
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix netns reference imbalance in conntrack kfuncs
The opts argument of the BPF conntrack kfuncs can point to a shared
map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read
opts->netns_id separately when acquiring and releasing the network
namespace reference.
The reference imbalance can occur as follows:
CPU 0 CPU 1
read opts->netns_id (-1)
skip get_net_ns_by_id()
write opts->netns_id (id)
read opts->netns_id (id)
put_net(net) /* no matching get */
The reverse transition leaks the reference. Repeating the unmatched put
can destroy a live namespace and crash later users.
The kernel reported:
Oops: general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]
RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700
Call Trace:
__sys_bpf+0x1662/0x50c0
__x64_sys_bpf+0x73/0xb0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: Fatal exception
Snapshot every input field of opts with READ_ONCE() before validating or
using it. The netns_id snapshot keeps the namespace get/put pair
balanced, while the other snapshots keep the remaining options from
changing partway through an invocation. The individual reads can still
observe an inconsistent combination during a concurrent update, but each
selected field value remains stable for that invocation.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix netns reference imbalance in conntrack kfuncs
The opts argument of the BPF conntrack kfuncs can point to a shared
map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read
opts->netns_id separately when acquiring and releasing the network
namespace reference.
The reference imbalance can occur as follows:
CPU 0 CPU 1
read opts->netns_id (-1)
skip get_net_ns_by_id()
write opts->netns_id (id)
read opts->netns_id (id)
put_net(net) /* no matching get */
The reverse transition leaks the reference. Repeating the unmatched put
can destroy a live namespace and crash later users.
The kernel reported:
Oops: general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]
RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700
Call Trace:
__sys_bpf+0x1662/0x50c0
__x64_sys_bpf+0x73/0xb0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: Fatal exception
Snapshot every input field of opts with READ_ONCE() before validating or
using it. The netns_id snapshot keeps the namespace get/put pair
balanced, while the other snapshots keep the remaining options from
changing partway through an invocation. The individual reads can still
observe an inconsistent combination during a concurrent update, but each
selected field value remains stable for that invocation.
🎖@cveNotify
🚨 CVE-2026-74716
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()
In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears
VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM
object and then calls madvise(MADV_DONTNEED), the PTEs will be
successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).
When userspace subsequently accesses the memory, drm_gem_shmem_fault()
handles the page fault and attempts to map the backing shmem page via
vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing
shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA
now has VM_MIXEDMAP set, won't this predictably trigger the explicit
assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn))
Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages()
pre-population with the handle_mm_fault() loop that was already used for
the import (dma-buf) path.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()
In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears
VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM
object and then calls madvise(MADV_DONTNEED), the PTEs will be
successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).
When userspace subsequently accesses the memory, drm_gem_shmem_fault()
handles the page fault and attempts to map the backing shmem page via
vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing
shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA
now has VM_MIXEDMAP set, won't this predictably trigger the explicit
assertion BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn))
Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages()
pre-population with the handle_mm_fault() loop that was already used for
the import (dma-buf) path.
🎖@cveNotify
🚨 CVE-2026-74717
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, return NULL on create error
Tracer creation can fail by returning either NULL or ERR_PTR.
The return value is stored without a check on the device, and users
treat ERR_PTR and NULL the same way.
This also causes a crash in the core dump logic, which is missing the
ERR_PTR check and ends up dereferencing it, as shown in the trace below.
Switch tracer creation to return NULL on failure only, so callers only
need a single NULL check.
Internal error: Oops: 0000000096000006 [#1] SMP
Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core
CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none)
Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core]
pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core]
lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core]
sp : ffff800081cf3c40
x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000
x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05
x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000
x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0
x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac
x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650
x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8
x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030
x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e
Call trace:
mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P)
mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core]
devlink_health_do_dump+0x9c/0x160
devlink_health_report+0x1c0/0x288
mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core]
process_one_work+0x15c/0x3d8
worker_thread+0x18c/0x320
kthread+0x148/0x228
ret_from_fork+0x10/0x20
Code: b9400000 5ac00800 7a401800 540003ca (3940a260)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x000000,00078031,75fce5a1,35fffe67
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, return NULL on create error
Tracer creation can fail by returning either NULL or ERR_PTR.
The return value is stored without a check on the device, and users
treat ERR_PTR and NULL the same way.
This also causes a crash in the core dump logic, which is missing the
ERR_PTR check and ends up dereferencing it, as shown in the trace below.
Switch tracer creation to return NULL on failure only, so callers only
need a single NULL check.
Internal error: Oops: 0000000096000006 [#1] SMP
Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core
CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none)
Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core]
pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core]
lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core]
sp : ffff800081cf3c40
x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000
x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05
x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000
x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0
x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac
x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650
x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8
x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030
x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e
Call trace:
mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P)
mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core]
devlink_health_do_dump+0x9c/0x160
devlink_health_report+0x1c0/0x288
mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core]
process_one_work+0x15c/0x3d8
worker_thread+0x18c/0x320
kthread+0x148/0x228
ret_from_fork+0x10/0x20
Code: b9400000 5ac00800 7a401800 540003ca (3940a260)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x000000,00078031,75fce5a1,35fffe67
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
🎖@cveNotify
🚨 CVE-2026-74718
In the Linux kernel, the following vulnerability has been resolved:
devlink: fix net namespace reference leak in reload
devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net
with a held reference. When the requested namespace differs from the
current one and the reload action is not DRIVER_REINIT, the function
returns -EOPNOTSUPP without releasing the reference. Add the missing
put_net() on this error path.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
devlink: fix net namespace reference leak in reload
devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net
with a held reference. When the requested namespace differs from the
current one and the reload action is not DRIVER_REINIT, the function
returns -EOPNOTSUPP without releasing the reference. Add the missing
put_net() on this error path.
🎖@cveNotify
🚨 CVE-2026-74719
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()
The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in
smc_llc_event_handler() stores an incoming qentry into the local LLC flow
without first checking whether a qentry is already pending. If a malicious or
buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is
active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the
pointer without freeing the previous allocation, leaking one kmalloc-96 object
per spurious message.
The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry
guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a
duplicate message when qentry is already occupied falls through to break and is
freed by the kfree(qentry) at the out: label, rather than silently leaking the
existing allocation.
The response direction (smc_llc_rx_response()) is unaffected: it already guards
with flow->qentry at the equivalent site and drops duplicate responses
correctly.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()
The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in
smc_llc_event_handler() stores an incoming qentry into the local LLC flow
without first checking whether a qentry is already pending. If a malicious or
buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is
active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the
pointer without freeing the previous allocation, leaking one kmalloc-96 object
per spurious message.
The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry
guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a
duplicate message when qentry is already occupied falls through to break and is
freed by the kfree(qentry) at the out: label, rather than silently leaking the
existing allocation.
The response direction (smc_llc_rx_response()) is unaffected: it already guards
with flow->qentry at the equivalent site and drops duplicate responses
correctly.
🎖@cveNotify
🚨 CVE-2026-74720
In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve pointer state for commuted arithmetic
When scalar += pointer is handled in adjust_ptr_min_max_vals(), the
destination register inherits the pointer state from the source pointer.
Copying only selected fields is fragile because pointer provenance is
tracked by several bpf_reg_state fields.
Use the caller's temporary offset register to preserve the scalar operand
while replacing the destination with the full pointer state. This preserves
the frame number for PTR_TO_STACK registers and keeps parent identity
fields consistent.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve pointer state for commuted arithmetic
When scalar += pointer is handled in adjust_ptr_min_max_vals(), the
destination register inherits the pointer state from the source pointer.
Copying only selected fields is fragile because pointer provenance is
tracked by several bpf_reg_state fields.
Use the caller's temporary offset register to preserve the scalar operand
while replacing the destination with the full pointer state. This preserves
the frame number for PTR_TO_STACK registers and keeps parent identity
fields consistent.
🎖@cveNotify
🚨 CVE-2026-74721
In the Linux kernel, the following vulnerability has been resolved:
accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()
Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma)
before returning an error code to the caller. This is incorrect:
amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling
amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo
that registration. Calling vm_ops->close() manually — which drops the
shmem pages_pin_count and the GEM object reference that backs the VMA —
before the mmap syscall has even returned causes those resources to be
released while the VMA is still alive. The kernel VMA teardown will call
vm_ops->close() a second time when the process later unmaps the range,
producing a reference count underflow.
Replace both hard-error returns with a deferred-fault approach that keeps
the VMA alive and retries page insertion through the HMM range-fault path.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()
Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma)
before returning an error code to the caller. This is incorrect:
amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling
amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo
that registration. Calling vm_ops->close() manually — which drops the
shmem pages_pin_count and the GEM object reference that backs the VMA —
before the mmap syscall has even returned causes those resources to be
released while the VMA is still alive. The kernel VMA teardown will call
vm_ops->close() a second time when the process later unmaps the range,
producing a reference count underflow.
Replace both hard-error returns with a deferred-fault approach that keeps
the VMA alive and retries page insertion through the HMM range-fault path.
🎖@cveNotify
🚨 CVE-2026-74722
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory leak in btrfs_do_encoded_write()
Local fuzzing of 6.12.94 has found the following memory leak:
Unreferenced object 0xffff888018050a80 (size 64):
comm "syz.0.17", pid 10297, jiffies 4294953601
hex dump (first 32 bytes):
00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................
backtrace (crc a8a6fc29):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline]
qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305
btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355
btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746
btrfs_encoded_write fs/btrfs/file.c:1482 [inline]
btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507
btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738
btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:47 [inline]
do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Unreferenced object 0xffff888018050a00 (size 64):
comm "syz.0.17", pid 10297, jiffies 4294953601
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................
90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................
backtrace (crc cb5c9580):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
kzalloc_noprof include/linux/slab.h:1014 [inline]
ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114
extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline]
__set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086
set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821
qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312
btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355
btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746
btrfs_encoded_write fs/btrfs/file.c:1482 [inline]
btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507
btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738
btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:47 [inline]
do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by freeing an extent changeset before returning from
btrfs_do_encoded_write().
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory leak in btrfs_do_encoded_write()
Local fuzzing of 6.12.94 has found the following memory leak:
Unreferenced object 0xffff888018050a80 (size 64):
comm "syz.0.17", pid 10297, jiffies 4294953601
hex dump (first 32 bytes):
00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................
backtrace (crc a8a6fc29):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline]
qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305
btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355
btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746
btrfs_encoded_write fs/btrfs/file.c:1482 [inline]
btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507
btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738
btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:47 [inline]
do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Unreferenced object 0xffff888018050a00 (size 64):
comm "syz.0.17", pid 10297, jiffies 4294953601
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................
90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................
backtrace (crc cb5c9580):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
kzalloc_noprof include/linux/slab.h:1014 [inline]
ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114
extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline]
__set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086
set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821
qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312
btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355
btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746
btrfs_encoded_write fs/btrfs/file.c:1482 [inline]
btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507
btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738
btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:47 [inline]
do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by freeing an extent changeset before returning from
btrfs_do_encoded_write().
🎖@cveNotify