🚨 CVE-2026-80612
In the Linux kernel, the following vulnerability has been resolved:
net: lwtunnel: Drop skb metadata before LWT encapsulation
skb metadata is meant for passing information between XDP and TC. It lives
in the skb headroom, immediately before skb->data. LWT programs cannot
access the __sk_buff->data_meta pseudo-pointer to metadata.
However, LWT encapsulation prepends outer headers, moving skb->data back
over the headroom where the metadata sits. On an RX-originated (forwarded)
packet that still carries XDP metadata this goes wrong in two different
ways, depending on the encap type:
1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull()
and silently overwrite the metadata that sits in the headroom.
2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move().
That helper expects metadata immediately before skb->data. But since
the IP output path runs LWT xmit before neighbour output has built
the outgoing L2 header, for forwarded packets skb->data points at the
L3 header while skb_mac_header() still points at the old L2 header.
skb_data_move() sees metadata ending at skb_mac_header(), not before
skb->data, warns and clears metadata:
WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90
CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1
RIP: 0010:skb_data_move+0x47/0x90
Call Trace:
<IRQ>
bpf_skb_change_head+0xe6/0x1a0
bpf_prog_...+0x213/0x2e3
run_lwt_bpf.isra.0+0x1d3/0x360
bpf_xmit+0x46/0xe0
lwtunnel_xmit+0xa1/0xf0
ip_finish_output2+0x1e7/0x5e0
ip_output+0x63/0x100
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0x9c/0x150
__napi_poll+0x2b/0x190
net_rx_action+0x40b/0x7f0
handle_softirqs+0xd2/0x270
do_softirq+0x3f/0x60
</IRQ>
That is what happens, as for how to fix it - a received packet that
carries metadata can reach an encap through any of the three LWT
redirect modes:
LWTUNNEL_STATE_INPUT_REDIRECT
ip6_rcv_finish
dst_input
lwtunnel_input
LWTUNNEL_STATE_OUTPUT_REDIRECT
ip6_rcv_finish
dst_input
ip6_forward
ip6_forward_finish
dst_output
lwtunnel_output
LWTUNNEL_STATE_XMIT_REDIRECT
ip6_rcv_finish
dst_input
ip6_forward
ip6_forward_finish
dst_output
ip6_output
ip6_finish_output
ip6_finish_output2
lwtunnel_xmit
Every encap funnels through the three LWT dispatch helpers, so drop the
metadata there, right before handing the skb to the encap op. This
single chokepoint covers all encap types and all three redirect modes:
- lwtunnel_input(): seg6, rpl, ila, seg6_local
- lwtunnel_output(): ioam6
- lwtunnel_xmit(): mpls, LWT BPF xmit
Alternatively, we could clear the metadata right after TC ingress hook.
That would require a compromise, however. Metadata would become
inaccessible from TC egress (in setups where it actually reaches the
hook it tact, that is without any L2 tunnels on path).
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: lwtunnel: Drop skb metadata before LWT encapsulation
skb metadata is meant for passing information between XDP and TC. It lives
in the skb headroom, immediately before skb->data. LWT programs cannot
access the __sk_buff->data_meta pseudo-pointer to metadata.
However, LWT encapsulation prepends outer headers, moving skb->data back
over the headroom where the metadata sits. On an RX-originated (forwarded)
packet that still carries XDP metadata this goes wrong in two different
ways, depending on the encap type:
1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skb_push()/skb_pull()
and silently overwrite the metadata that sits in the headroom.
2) BPF LWT xmit calls bpf_skb_change_head(), which uses skb_data_move().
That helper expects metadata immediately before skb->data. But since
the IP output path runs LWT xmit before neighbour output has built
the outgoing L2 header, for forwarded packets skb->data points at the
L3 header while skb_mac_header() still points at the old L2 header.
skb_data_move() sees metadata ending at skb_mac_header(), not before
skb->data, warns and clears metadata:
WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skb_data_move+0x47/0x90
CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1
RIP: 0010:skb_data_move+0x47/0x90
Call Trace:
<IRQ>
bpf_skb_change_head+0xe6/0x1a0
bpf_prog_...+0x213/0x2e3
run_lwt_bpf.isra.0+0x1d3/0x360
bpf_xmit+0x46/0xe0
lwtunnel_xmit+0xa1/0xf0
ip_finish_output2+0x1e7/0x5e0
ip_output+0x63/0x100
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0x9c/0x150
__napi_poll+0x2b/0x190
net_rx_action+0x40b/0x7f0
handle_softirqs+0xd2/0x270
do_softirq+0x3f/0x60
</IRQ>
That is what happens, as for how to fix it - a received packet that
carries metadata can reach an encap through any of the three LWT
redirect modes:
LWTUNNEL_STATE_INPUT_REDIRECT
ip6_rcv_finish
dst_input
lwtunnel_input
LWTUNNEL_STATE_OUTPUT_REDIRECT
ip6_rcv_finish
dst_input
ip6_forward
ip6_forward_finish
dst_output
lwtunnel_output
LWTUNNEL_STATE_XMIT_REDIRECT
ip6_rcv_finish
dst_input
ip6_forward
ip6_forward_finish
dst_output
ip6_output
ip6_finish_output
ip6_finish_output2
lwtunnel_xmit
Every encap funnels through the three LWT dispatch helpers, so drop the
metadata there, right before handing the skb to the encap op. This
single chokepoint covers all encap types and all three redirect modes:
- lwtunnel_input(): seg6, rpl, ila, seg6_local
- lwtunnel_output(): ioam6
- lwtunnel_xmit(): mpls, LWT BPF xmit
Alternatively, we could clear the metadata right after TC ingress hook.
That would require a compromise, however. Metadata would become
inaccessible from TC egress (in setups where it actually reaches the
hook it tact, that is without any L2 tunnels on path).
🎖@cveNotify
🚨 CVE-2026-80613
In the Linux kernel, the following vulnerability has been resolved:
veth: fix NAPI leak in XDP enable error path
During XDP enablement in veth, if xdp_rxq_info_reg() or
xdp_rxq_info_reg_mem_model() fails, the driver rolls back the changes.
However, the rollback loop:
for (i--; i >= start; i--) {
decrements the loop index 'i' before the first iteration. This
correctly skips unregistering the rxq for the failed index 'i' (as
registration failed or was already cleaned up), but it also
erroneously skips calling netif_napi_deli() for rq[i].xdp_napi.
Since netif_napi_add() was already called for index 'i', this leaves
a dangling napi_struct in the device's napi_list. When the veth
device is later destroyed, the freed queue memory (which contains the
leaked NAPI structure) can be reused.
The subsequent device teardown iterates the NAPI list and
corrupts the reallocated memory, leading to UAF.
Fix this by explicitly deleting the NAPI association for the failed
index 'i' before rolling back the successfully configured queues.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
veth: fix NAPI leak in XDP enable error path
During XDP enablement in veth, if xdp_rxq_info_reg() or
xdp_rxq_info_reg_mem_model() fails, the driver rolls back the changes.
However, the rollback loop:
for (i--; i >= start; i--) {
decrements the loop index 'i' before the first iteration. This
correctly skips unregistering the rxq for the failed index 'i' (as
registration failed or was already cleaned up), but it also
erroneously skips calling netif_napi_deli() for rq[i].xdp_napi.
Since netif_napi_add() was already called for index 'i', this leaves
a dangling napi_struct in the device's napi_list. When the veth
device is later destroyed, the freed queue memory (which contains the
leaked NAPI structure) can be reused.
The subsequent device teardown iterates the NAPI list and
corrupts the reallocated memory, leading to UAF.
Fix this by explicitly deleting the NAPI association for the failed
index 'i' before rolling back the successfully configured queues.
🎖@cveNotify
🚨 CVE-2026-80614
In the Linux kernel, the following vulnerability has been resolved:
net: emac: Fix NULL pointer dereference in emac_probe
Move devm_request_irq() after devm_platform_ioremap_resource() so that
dev->emacp is mapped before the interrupt handler can fire. An early
interrupt hitting emac_irq() would dereference the NULL dev->emacp and
crash.
Also remove redundant error message. devm_platform_ioremap_resource()
already returns an error message with dev_err_probe().
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: emac: Fix NULL pointer dereference in emac_probe
Move devm_request_irq() after devm_platform_ioremap_resource() so that
dev->emacp is mapped before the interrupt handler can fire. An early
interrupt hitting emac_irq() would dereference the NULL dev->emacp and
crash.
Also remove redundant error message. devm_platform_ioremap_resource()
already returns an error message with dev_err_probe().
🎖@cveNotify
🚨 CVE-2026-80615
In the Linux kernel, the following vulnerability has been resolved:
net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone
kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the
structure to the options_len, which is then initialized to zero.
Later, we're initializing the structure by copying the tunnel info
together with the options, and this triggers a warning for a potential
memcpy overflow, since the compiler estimates that the options can't
fit into the structure, even though the memory for them is actually
allocated.
memcpy: detected buffer overflow: 104 byte write of buffer size 96
WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report
skb_tunnel_info_unclone+0x179/0x190
geneve_xmit+0x7fe/0xe00
The issue is triggered when built with clang and source fortification.
Fix that by doing the copy in two stages: first - the main data with
the options_len, then the options. This way the correct length should
be known at the time of the copy.
It would be better if the options_len never changed after allocation,
but the allocation code is a little separate from the initialization
and it would be awkward and potentially dangerous to return a struct
with options_len set to a non-zero value from the metadata_dst_alloc().
Another option would be to use ip_tunnel_info_opts_set(), but it is
doing too many unnecessary operations for the use case here.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone
kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the
structure to the options_len, which is then initialized to zero.
Later, we're initializing the structure by copying the tunnel info
together with the options, and this triggers a warning for a potential
memcpy overflow, since the compiler estimates that the options can't
fit into the structure, even though the memory for them is actually
allocated.
memcpy: detected buffer overflow: 104 byte write of buffer size 96
WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report
skb_tunnel_info_unclone+0x179/0x190
geneve_xmit+0x7fe/0xe00
The issue is triggered when built with clang and source fortification.
Fix that by doing the copy in two stages: first - the main data with
the options_len, then the options. This way the correct length should
be known at the time of the copy.
It would be better if the options_len never changed after allocation,
but the allocation code is a little separate from the initialization
and it would be awkward and potentially dangerous to return a struct
with options_len set to a non-zero value from the metadata_dst_alloc().
Another option would be to use ip_tunnel_info_opts_set(), but it is
doing too many unnecessary operations for the use case here.
🎖@cveNotify
🚨 CVE-2026-80617
In the Linux kernel, the following vulnerability has been resolved:
net: airoha: fix foe_check_time allocation size
foe_check_time is declared as u16 pointer but was allocated with
only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
it writes beyond the allocated buffer, causing heap buffer overflow and
potential kernel crash.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: airoha: fix foe_check_time allocation size
foe_check_time is declared as u16 pointer but was allocated with
only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
it writes beyond the allocated buffer, causing heap buffer overflow and
potential kernel crash.
🎖@cveNotify
🚨 CVE-2026-80619
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix potential UAF in aa_replace_profiles
The function aa_replace_profiles was accessing udata->size after calling
aa_put_loaddata(udata), causing a potential UAF.
Fixed this by saving the size to a local variable before dropping the
reference.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix potential UAF in aa_replace_profiles
The function aa_replace_profiles was accessing udata->size after calling
aa_put_loaddata(udata), causing a potential UAF.
Fixed this by saving the size to a local variable before dropping the
reference.
🎖@cveNotify
🚨 CVE-2026-80622
In the Linux kernel, the following vulnerability has been resolved:
char: tlclk: fix use-after-free in tlclk_cleanup()
This patch improves the module cleanup process in the tlclk driver to
prevent potential use-after-free and race conditions.
Currently, the file_operations structure does not specify the .owner
field, which could allow the module to be unloaded while user-space
processes are still interacting with the device. Additionally, the
tlclk_cleanup() function frees the alarm_events memory before ensuring
that blocked processes in the waitqueue are fully awakened and that the
switchover_timer has completed.
To address these cases, this patch:
- Sets '.owner = THIS_MODULE' in tlclk_fops to safely defer module
unloading while the device is in use.
- Updates tlclk_cleanup() to explicitly wake up all blocked readers
(wake_up_all), properly release hardware I/O regions, and safely
delete the timer (timer_delete_sync) prior to freeing memory.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
char: tlclk: fix use-after-free in tlclk_cleanup()
This patch improves the module cleanup process in the tlclk driver to
prevent potential use-after-free and race conditions.
Currently, the file_operations structure does not specify the .owner
field, which could allow the module to be unloaded while user-space
processes are still interacting with the device. Additionally, the
tlclk_cleanup() function frees the alarm_events memory before ensuring
that blocked processes in the waitqueue are fully awakened and that the
switchover_timer has completed.
To address these cases, this patch:
- Sets '.owner = THIS_MODULE' in tlclk_fops to safely defer module
unloading while the device is in use.
- Updates tlclk_cleanup() to explicitly wake up all blocked readers
(wake_up_all), properly release hardware I/O regions, and safely
delete the timer (timer_delete_sync) prior to freeing memory.
🎖@cveNotify
🚨 CVE-2026-80630
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen
Whenever fq_codel drops packets during peek, it calls
qdisc_tree_reduce_backlog. An issue arises because it calls
qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops
to zero, but peek returns an skb, the parent's qlen_notify callback will be
executed even though fq_codel still has 1 packet on the queue and, thus,
will mistakenly deactivate the parent's class causing issues like a recent
report [1] and a wild memory access in qfq:
[ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI
[ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
[ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full)
[ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq
[ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216
[ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000
[ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000
[ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024
[ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000
[ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578
[ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000
[ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0
[ 29.376103][ T360] PKRU: 55555554
[ 29.376258][ T360] Call Trace:
[ 29.376401][ T360] <TASK>
...
[ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq
[ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057)
[ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096)
[ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)
[ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556)
Fix this by only calling qdisc_tree_reduce_backlog in peek after the
qlen is restored.
[1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen
Whenever fq_codel drops packets during peek, it calls
qdisc_tree_reduce_backlog. An issue arises because it calls
qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops
to zero, but peek returns an skb, the parent's qlen_notify callback will be
executed even though fq_codel still has 1 packet on the queue and, thus,
will mistakenly deactivate the parent's class causing issues like a recent
report [1] and a wild memory access in qfq:
[ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI
[ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
[ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full)
[ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq
[ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216
[ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000
[ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000
[ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024
[ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000
[ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578
[ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000
[ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0
[ 29.376103][ T360] PKRU: 55555554
[ 29.376258][ T360] Call Trace:
[ 29.376401][ T360] <TASK>
...
[ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq
[ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057)
[ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096)
[ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)
[ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556)
Fix this by only calling qdisc_tree_reduce_backlog in peek after the
qlen is restored.
[1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/
🎖@cveNotify
🚨 CVE-2026-80631
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lzo: reject compressed segment that overflows the compressed input
lzo_decompress_bio() validates each on-disk segment length seg_len only
against the workspace cbuf size, not against the compressed input size
(compressed_len, the total folio bytes of the bio). A crafted extent can
carry a segment whose seg_len passes the cbuf check but runs past the end
of the bio, so copy_compressed_segment() walks off the last folio:
get_current_folio() then returns the NULL folio from bio_next_folio(), and
with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults.
BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383)
Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29
Workqueue: btrfs-endio simple_end_io_work
kasan_report (mm/kasan/report.c:590)
lzo_decompress_bio (fs/btrfs/lzo.c:383)
end_bbio_compressed_read (fs/btrfs/compression.c:1065)
btrfs_bio_end_io (fs/btrfs/bio.c:135)
btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285)
simple_end_io_work
process_one_work
worker_thread
Reject any segment whose payload would extend beyond compressed_len before
copying it, treating it as corruption like the other on-disk validation
failures in this function.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lzo: reject compressed segment that overflows the compressed input
lzo_decompress_bio() validates each on-disk segment length seg_len only
against the workspace cbuf size, not against the compressed input size
(compressed_len, the total folio bytes of the bio). A crafted extent can
carry a segment whose seg_len passes the cbuf check but runs past the end
of the bio, so copy_compressed_segment() walks off the last folio:
get_current_folio() then returns the NULL folio from bio_next_folio(), and
with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults.
BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383)
Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29
Workqueue: btrfs-endio simple_end_io_work
kasan_report (mm/kasan/report.c:590)
lzo_decompress_bio (fs/btrfs/lzo.c:383)
end_bbio_compressed_read (fs/btrfs/compression.c:1065)
btrfs_bio_end_io (fs/btrfs/bio.c:135)
btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285)
simple_end_io_work
process_one_work
worker_thread
Reject any segment whose payload would extend beyond compressed_len before
copying it, treating it as corruption like the other on-disk validation
failures in this function.
🎖@cveNotify
🚨 CVE-2026-80633
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Take dma_resv lock before dma_buf_unpin() in release path
dma_buf_unpin() requires the caller to hold the exporter's dma_resv
lock:
void dma_buf_unpin(struct dma_buf_attachment *attach)
{
...
dma_resv_assert_held(dmabuf->resv);
...
}
iopt_release_pages() calls dma_buf_unpin() without taking that lock,
so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases
the last reference on a DMABUF-backed iopt_pages triggers a WARN.
This was hit while running tools/testing/selftests/iommu/iommufd:
WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70
RIP: 0010:dma_buf_unpin+0x62/0x70
Call Trace:
<TASK>
dma_buf_unpin+0x62/0x70
iopt_release_pages+0xe4/0x190
iopt_unmap_iova_range+0x1c7/0x290
iopt_unmap_all+0x1a/0x30
iommufd_ioas_destroy+0x1d/0x50
iommufd_fops_release+0x93/0x150
__fput+0xfc/0x2c0
__x64_sys_close+0x3d/0x80
do_syscall_64+0x65/0x180
</TASK>
Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(),
matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the
reservation lock internally, so it must remain outside the locked region.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Take dma_resv lock before dma_buf_unpin() in release path
dma_buf_unpin() requires the caller to hold the exporter's dma_resv
lock:
void dma_buf_unpin(struct dma_buf_attachment *attach)
{
...
dma_resv_assert_held(dmabuf->resv);
...
}
iopt_release_pages() calls dma_buf_unpin() without taking that lock,
so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases
the last reference on a DMABUF-backed iopt_pages triggers a WARN.
This was hit while running tools/testing/selftests/iommu/iommufd:
WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70
RIP: 0010:dma_buf_unpin+0x62/0x70
Call Trace:
<TASK>
dma_buf_unpin+0x62/0x70
iopt_release_pages+0xe4/0x190
iopt_unmap_iova_range+0x1c7/0x290
iopt_unmap_all+0x1a/0x30
iommufd_ioas_destroy+0x1d/0x50
iommufd_fops_release+0x93/0x150
__fput+0xfc/0x2c0
__x64_sys_close+0x3d/0x80
do_syscall_64+0x65/0x180
</TASK>
Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(),
matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the
reservation lock internally, so it must remain outside the locked region.
🎖@cveNotify
🚨 CVE-2026-80634
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps
inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the
decrement still happens and wraps it to 255. The break only leaves
the inner switch -- a later path entry can set info->indev back to
a real device, and we end up returning with num_encaps == 255.
nft_dev_forward_path() then walks info.encap[] (size 2) up to
num_encaps, which means an OOB stack read and a bogus count copied
into the route descriptor.
Should only happen on a malformed bridge path stack, hence the WARN,
but worth handling sanely. Move the decrement out of the WARN.
[ While at this, remove the WARN_ON_ONCE since this can only happen
with a buggy bridge path stack --pablo ].
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps
inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the
decrement still happens and wraps it to 255. The break only leaves
the inner switch -- a later path entry can set info->indev back to
a real device, and we end up returning with num_encaps == 255.
nft_dev_forward_path() then walks info.encap[] (size 2) up to
num_encaps, which means an OOB stack read and a bogus count copied
into the route descriptor.
Should only happen on a malformed bridge path stack, hence the WARN,
but worth handling sanely. Move the decrement out of the WARN.
[ While at this, remove the WARN_ON_ONCE since this can only happen
with a buggy bridge path stack --pablo ].
🎖@cveNotify
🚨 CVE-2026-80635
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix OOB read from short trigger BA firmware response
The firmware response length is only checked against sizeof(*rsp) (20
bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
at buf + 20 without verifying the response contains it. This causes an
out-of-bounds read of stale heap data, corrupting the BA session state.
Add validation that the response includes the candidate data.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix OOB read from short trigger BA firmware response
The firmware response length is only checked against sizeof(*rsp) (20
bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
at buf + 20 without verifying the response contains it. This causes an
out-of-bounds read of stale heap data, corrupting the BA session state.
Add validation that the response includes the candidate data.
🎖@cveNotify
🚨 CVE-2026-80637
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: fix unaligned memory access in timestamp adjustment
Use get_unaligned_be32() and put_unaligned_be32() to safely read and
write the timestamp fields. This prevents performance degradation due to
unaligned memory access or even a crash on strict alignment
architectures.
This follows the implementation of timestamp parsing in the networking
stack at tcp_parse_options() and synproxy_parse_options().
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: fix unaligned memory access in timestamp adjustment
Use get_unaligned_be32() and put_unaligned_be32() to safely read and
write the timestamp fields. This prevents performance degradation due to
unaligned memory access or even a crash on strict alignment
architectures.
This follows the implementation of timestamp parsing in the networking
stack at tcp_parse_options() and synproxy_parse_options().
🎖@cveNotify
🚨 CVE-2026-80638
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent
[BUG]
Unlinking a refcounted file whose refcount tree has leaf blocks
triggers a fortify panic due to an out-of-bounds write.
[CAUSE]
When the last leaf block is removed from a refcount tree,
ocfs2_remove_refcount_extent() converts the root back to leaf mode
with a bulk memset on &rb->rf_records. rf_records sits in an anonymous
union with rf_list. rf_list.l_tree_depth aliases rf_records.rl_count,
and is 0 for a single-level tree. With rl_count equal to 0, the memset
writes past the 16-byte declared size of rf_records, which the fortify
checker catches.
[FIX]
Replace the bulk memset on &rb->rf_records with a correctly-bounded
memset on rl_recs[] alone, after setting rl_count to the correct value.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent
[BUG]
Unlinking a refcounted file whose refcount tree has leaf blocks
triggers a fortify panic due to an out-of-bounds write.
[CAUSE]
When the last leaf block is removed from a refcount tree,
ocfs2_remove_refcount_extent() converts the root back to leaf mode
with a bulk memset on &rb->rf_records. rf_records sits in an anonymous
union with rf_list. rf_list.l_tree_depth aliases rf_records.rl_count,
and is 0 for a single-level tree. With rl_count equal to 0, the memset
writes past the 16-byte declared size of rf_records, which the fortify
checker catches.
[FIX]
Replace the bulk memset on &rb->rf_records with a correctly-bounded
memset on rl_recs[] alone, after setting rl_count to the correct value.
🎖@cveNotify
🚨 CVE-2026-80645
In the Linux kernel, the following vulnerability has been resolved:
rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()
With a list_for_each() loop, if we don't find the item we are looking for
in the list, then the loop exits with the iterator, which is "dbell" in
this loop, pointing to invalid memory.
This code uses the "found" variable to determine if we have found the
doorbell we are looking for or not. However, the problem that the "found"
variable needs to be set to false at the start of each iteration,
otherwise after the first correct doorbell, then everything is marked as
found.
Reset the "found" to false at the start of the iteration and move the
variable inside the loop.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()
With a list_for_each() loop, if we don't find the item we are looking for
in the list, then the loop exits with the iterator, which is "dbell" in
this loop, pointing to invalid memory.
This code uses the "found" variable to determine if we have found the
doorbell we are looking for or not. However, the problem that the "found"
variable needs to be set to false at the start of each iteration,
otherwise after the first correct doorbell, then everything is marked as
found.
Reset the "found" to false at the start of the iteration and move the
variable inside the loop.
🎖@cveNotify
🚨 CVE-2026-80646
In the Linux kernel, the following vulnerability has been resolved:
ipv6: guard against possible NULL deref in __in6_dev_stats_get()
dev_get_by_index_rcu() could return NULL if the original physical
device is unregistered.
Found by Sashiko.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ipv6: guard against possible NULL deref in __in6_dev_stats_get()
dev_get_by_index_rcu() could return NULL if the original physical
device is unregistered.
Found by Sashiko.
🎖@cveNotify
🚨 CVE-2026-80649
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix OOB in scmi_power_name_get()
scmi_power_name_get() does not validate the domain number passed by the
external caller, which may lead to an out-of-bounds access.
Fix this by returning "unknown" for invalid domains, like
scmi_reset_name_get() does.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix OOB in scmi_power_name_get()
scmi_power_name_get() does not validate the domain number passed by the
external caller, which may lead to an out-of-bounds access.
Fix this by returning "unknown" for invalid domains, like
scmi_reset_name_get() does.
🎖@cveNotify
🚨 CVE-2026-80653
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Add slave_destroy interface for v3 hw
WARNING is triggered when executing link reset of remote PHY and rmmod
SAS driver simultaneously. Following is the WARNING log:
WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0
Call trace:
__device_links_no_driver+0xb4/0xc0
device_links_driver_cleanup+0xb0/0xfc
__device_release_driver+0x198/0x23c
device_release_driver+0x38/0x50
bus_remove_device+0x130/0x140
device_del+0x184/0x434
__scsi_remove_device+0x118/0x150
scsi_remove_target+0x1bc/0x240
sas_rphy_remove+0x90/0x94
sas_rphy_delete+0x24/0x3c
sas_destruct_devices+0x64/0xa0 [libsas]
sas_revalidate_domain+0xe4/0x150 [libsas]
process_one_work+0x1e0/0x46c
worker_thread+0x15c/0x464
kthread+0x160/0x170
ret_from_fork+0x10/0x20
---[ end trace 71e059eb58f85d4a ]---
During SAS phy up, link->status is set to DL_STATE_AVAILABLE in
device_links_driver_bound, then this setting influences
__device_links_no_driver() before driver rmmod and caused WARNING.
Add the slave_destroy interface to make sure link is removed after flush
workque.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Add slave_destroy interface for v3 hw
WARNING is triggered when executing link reset of remote PHY and rmmod
SAS driver simultaneously. Following is the WARNING log:
WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0
Call trace:
__device_links_no_driver+0xb4/0xc0
device_links_driver_cleanup+0xb0/0xfc
__device_release_driver+0x198/0x23c
device_release_driver+0x38/0x50
bus_remove_device+0x130/0x140
device_del+0x184/0x434
__scsi_remove_device+0x118/0x150
scsi_remove_target+0x1bc/0x240
sas_rphy_remove+0x90/0x94
sas_rphy_delete+0x24/0x3c
sas_destruct_devices+0x64/0xa0 [libsas]
sas_revalidate_domain+0xe4/0x150 [libsas]
process_one_work+0x1e0/0x46c
worker_thread+0x15c/0x464
kthread+0x160/0x170
ret_from_fork+0x10/0x20
---[ end trace 71e059eb58f85d4a ]---
During SAS phy up, link->status is set to DL_STATE_AVAILABLE in
device_links_driver_bound, then this setting influences
__device_links_no_driver() before driver rmmod and caused WARNING.
Add the slave_destroy interface to make sure link is removed after flush
workque.
🎖@cveNotify
🚨 CVE-2026-80656
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: Add a sanity check for btree node size
Syzbot reported an uninit-value bug in [1] with a corrupted HFS+ image,
during the file system mounting process, specifically while loading the
catalog, a corrupted node_size value of 1 caused the rec_off argument
passed to hfs_bnode_read_u16() (within hfs_bnode_find()) to be excessively
large. Consequently, the function failed to return a valid value to
initialize the off variable, triggering the bug [1].
Every node starts from BTree node descriptor: struct hfs_bnode_desc.
So, the size of node cannot be lesser than that. However, technical
specification declares that: "The node size (which is expressed in bytes)
must be power of two, from 512 through 32,768, inclusive." Add a check
for btree node size base on technical specification.
[1]
BUG: KMSAN: uninit-value in hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_btree_open+0x169a/0x1e40 fs/hfsplus/btree.c:382
hfsplus_fill_super+0x111f/0x2770 fs/hfsplus/super.c:553
get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694
get_tree_bdev+0x38/0x50 fs/super.c:1717
hfsplus_get_tree+0x35/0x40 fs/hfsplus/super.c:709
vfs_get_tree+0xb3/0x5d0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: Add a sanity check for btree node size
Syzbot reported an uninit-value bug in [1] with a corrupted HFS+ image,
during the file system mounting process, specifically while loading the
catalog, a corrupted node_size value of 1 caused the rec_off argument
passed to hfs_bnode_read_u16() (within hfs_bnode_find()) to be excessively
large. Consequently, the function failed to return a valid value to
initialize the off variable, triggering the bug [1].
Every node starts from BTree node descriptor: struct hfs_bnode_desc.
So, the size of node cannot be lesser than that. However, technical
specification declares that: "The node size (which is expressed in bytes)
must be power of two, from 512 through 32,768, inclusive." Add a check
for btree node size base on technical specification.
[1]
BUG: KMSAN: uninit-value in hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_btree_open+0x169a/0x1e40 fs/hfsplus/btree.c:382
hfsplus_fill_super+0x111f/0x2770 fs/hfsplus/super.c:553
get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694
get_tree_bdev+0x38/0x50 fs/super.c:1717
hfsplus_get_tree+0x35/0x40 fs/hfsplus/super.c:709
vfs_get_tree+0xb3/0x5d0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline]
🎖@cveNotify
🚨 CVE-2026-80661
In the Linux kernel, the following vulnerability has been resolved:
ufs: core: tracing: Do not dereference pointers in TP_printk()
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
pointer to the hba structure as an argument for the tracepoint and then in
TP_printk() the printing of the dev_name from the ring buffer was
converted to using the dev dereferenced pointer from the hba saved
pointer.
This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time it
is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove the
possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ufs: core: tracing: Do not dereference pointers in TP_printk()
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
pointer to the hba structure as an argument for the tracepoint and then in
TP_printk() the printing of the dev_name from the ring buffer was
converted to using the dev dereferenced pointer from the hba saved
pointer.
This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time it
is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove the
possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
🎖@cveNotify
🚨 CVE-2026-80662
In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size
The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58
bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing
64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512,
eight times the actual on-device size.
header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the
RAS capability iomap, overrunning the 88-byte mapping by 448 bytes.
The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE
(512) bytes from its source. For the CPER caller the source is
struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a
stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes
of kernel stack into the trace event ring buffer where userspace can
read it via tracefs.
Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it,
bringing all iomap readers into agreement on 16 dwords. Userspace tools
such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32)
header_log layout in the cxl_aer_uncorrectable_error trace event. Add
CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event
__array and its memcpy to preserve that ABI. Both callers now pass a
zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only
the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware;
the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring
buffer layout intact.
[ dj: Replaced 64 with SZ_64 per RichardC ]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size
The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58
bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing
64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512,
eight times the actual on-device size.
header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the
RAS capability iomap, overrunning the 88-byte mapping by 448 bytes.
The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE
(512) bytes from its source. For the CPER caller the source is
struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a
stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes
of kernel stack into the trace event ring buffer where userspace can
read it via tracefs.
Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it,
bringing all iomap readers into agreement on 16 dwords. Userspace tools
such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32)
header_log layout in the cxl_aer_uncorrectable_error trace event. Add
CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event
__array and its memcpy to preserve that ABI. Both callers now pass a
zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only
the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware;
the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring
buffer layout intact.
[ dj: Replaced 64 with SZ_64 per RichardC ]
🎖@cveNotify