HIGH7.8
Уязвимость функции skb_try_coalesce() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
ALT-PU-2026-8752-20Обновление пакета kernel-image-rt в ветке sisyphus
Серьёзность:
Закрытые проблемы (235)
HIGH7.8
Уязвимость реализации сетевого протокола RDS ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии и вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0
CVSS:2.0/AV:L/AC:M/Au:N/C:C/I:C/A:CHIGH8.8
Уязвимость функции cifs_get_spnego_key() инструмента cifs.upcall пакета cifs-utils ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии до уровня root и выполнить произвольный код
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CHIGH8.8
Уязвимость сетевого компонента skbuff ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CCRITICAL9.1
Уязвимость функции nft_inner_parse_l2l3() модуля net/netfilter/nft_inner.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NCVSS 2.0КРИТИЧЕСКАЯ 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:NHIGH7.0
Уязвимость компонента drivers/net/ppp/ppp_generic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/rds: reset op_nents when zerocopy page pin fails When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/03014551938a0887fa55f18ce49b70158a9c0113
- https://git.kernel.org/stable/c/0bbbff00a15b1df2cac9014d6cf4b6890f473353
- https://git.kernel.org/stable/c/290e833d1acb1093bc121fcdc97f5e6161157479
- https://git.kernel.org/stable/c/640e37f58f991546a87540d067279c2c1fa9fe51
- https://git.kernel.org/stable/c/9115669faedccdda100428e2d26fd0aac8c50799
- https://git.kernel.org/stable/c/c6e51512a784c4a7b86e1a044988696e3b3721fa
- https://git.kernel.org/stable/c/d84ce1786ce40fdd3dd98db47aec5527817e1ef6
- https://git.kernel.org/stable/c/e174929793195e0cd6a4adb0cad731b39f9019b4
- https://github.com/v12-security/pocs/tree/main/pintheft
- http://www.openwall.com/lists/oss-security/2026/05/21/2
- https://access.redhat.com/security/cve/CVE-2026-43494
- https://bugzilla.redhat.com/show_bug.cgi?id=2480434
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43494.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched. As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to ' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list. Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb. The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb. Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee
- https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196
- https://git.kernel.org/stable/c/48f6a5356a33dd78e7144ae1faef95ffc990aae0
- https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349
- https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20
- https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991
- https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8
- https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:19540
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19664
- https://access.redhat.com/errata/RHSA-2026:19666
- https://access.redhat.com/errata/RHSA-2026:19705
- https://access.redhat.com/errata/RHSA-2026:19711
- https://access.redhat.com/errata/RHSA-2026:19875
- https://access.redhat.com/errata/RHSA-2026:20051
- https://access.redhat.com/errata/RHSA-2026:20054
- https://access.redhat.com/errata/RHSA-2026:20087
- https://access.redhat.com/errata/RHSA-2026:20129
- https://access.redhat.com/errata/RHSA-2026:20130
- https://access.redhat.com/errata/RHSA-2026:20299
- https://access.redhat.com/errata/RHSA-2026:20593
- https://access.redhat.com/errata/RHSA-2026:21656
- https://access.redhat.com/errata/RHSA-2026:21690
- https://access.redhat.com/errata/RHSA-2026:21695
- https://access.redhat.com/errata/RHSA-2026:21702
- https://access.redhat.com/errata/RHSA-2026:23233
- https://access.redhat.com/errata/RHSA-2026:23240
- https://access.redhat.com/errata/RHSA-2026:23245
- https://access.redhat.com/errata/RHSA-2026:23468
- https://access.redhat.com/errata/RHSA-2026:23469
- https://access.redhat.com/errata/RHSA-2026:23470
- https://access.redhat.com/errata/RHSA-2026:23471
- https://access.redhat.com/errata/RHSA-2026:24814
- https://access.redhat.com/errata/RHSA-2026:25044
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/security/cve/CVE-2026-43503
- https://bugzilla.redhat.com/show_bug.cgi?id=2480902
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43503.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0f3d9dd5e1fd52b39e25328307c6a694e994ffe3
- https://git.kernel.org/stable/c/26d3339e465e54107bd85884341d1609c5300d6a
- https://git.kernel.org/stable/c/2c88b2d96e1d4d0c7c4589a4593d4cdee6d332d6
- https://git.kernel.org/stable/c/32ce55d424395904986f5066f8755f6cb9993377
- https://git.kernel.org/stable/c/5828b9e5b272ecff7cf5d345128d3de7324117f7
- https://git.kernel.org/stable/c/85a2f30e40f7468db732f55659bc6318874f49af
- https://git.kernel.org/stable/c/b4b5a20bed82130da2f2818f04d52378952fbd0b
- https://git.kernel.org/stable/c/fc39753b7f92e09177777e9c648afe5aa3abb81f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()
CO-RE accessor strings are colon-separated indices that describe a path
from a root BTF type to a target field, e.g. "0:1:2" walks through
nested struct members. bpf_core_parse_spec() parses each component with
sscanf("%d"), so negative values like -1 are silently accepted. The
subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the
upper bound and always pass for negative values because C integer
promotion converts the __u16 btf_vlen result to int, making the
comparison (int)(-1) >= (int)(N) false for any positive N.
When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff,
producing an out-of-bounds read far past the members array. A crafted
BPF program with a negative CO-RE accessor on any struct that exists in
vmlinux BTF (e.g. task_struct) crashes the kernel deterministically
during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y
(default on major distributions). The bug is reachable with CAP_BPF:
BUG: unable to handle page fault for address: ffffed11818b6626
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full)
RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354)
RAX: 00000000ffffffff
Call Trace:
bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321)
bpf_core_apply (kernel/bpf/btf.c:9507)
check_core_relo (kernel/bpf/verifier.c:19475)
bpf_check (kernel/bpf/verifier.c:26031)
bpf_prog_load (kernel/bpf/syscall.c:3089)
__sys_bpf (kernel/bpf/syscall.c:6228)
CO-RE accessor indices are inherently non-negative (struct member index,
array element index, or enumerator index), so reject them immediately
after parsing.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1c22483a2c4bbf747787f328392ca3e68619c4dc
- https://git.kernel.org/stable/c/36a9012f76ba8d9189ae56a1f8bb7c87c07a1f3a
- https://git.kernel.org/stable/c/3ff85ae79e1a74baeb916b78a63d821f6d19a994
- https://git.kernel.org/stable/c/669349b4612c26b3d7aacfa99d7174681bd19223
- https://git.kernel.org/stable/c/76f2ebaf79a9ae6d0737b87f045fe769e425d78f
- https://git.kernel.org/stable/c/99dbab7b5a12d8f58d5b0aa2f7a1fe656a70f4b2
- https://git.kernel.org/stable/c/a9e777f856cd2f1efc106afc7bf21aef868509d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: cap upcall PID array size and pre-size vport replies
The vport netlink reply helpers allocate a fixed-size skb with
nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
array via ovs_vport_get_upcall_portids(). Since
ovs_vport_set_upcall_portids() accepts any non-zero multiple of
sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
array large enough to overflow the reply buffer, causing nla_put() to
fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with
unprivileged user namespaces enabled (e.g., Ubuntu default), this is
reachable via unshare -Urn since OVS vport mutation operations use
GENL_UNS_ADMIN_PERM.
kernel BUG at net/openvswitch/datapath.c:2414!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
Call Trace:
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
genl_rcv_msg (net/netlink/genetlink.c:1194)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
genl_rcv (net/netlink/genetlink.c:1219)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
__sys_sendto (net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Kernel panic - not syncing: Fatal exception
Reject attempts to set more PIDs than nr_cpu_ids in
ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply
size in ovs_vport_cmd_msg_size() based on that bound, similar to the
existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already
used by the per-CPU dispatch configuration on the datapath side
(ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the
two sides stay consistent.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1d6c02b86329883aa467a3a61f8d34369db73a2f
- https://git.kernel.org/stable/c/2091c6aa0df6aba47deb5c8ab232b1cb60af3519
- https://git.kernel.org/stable/c/8d59b80e69dddb665eb2de36e62859ab2073470e
- https://git.kernel.org/stable/c/b39f763d720d623218bc1d95ace6855d7b474e81
- https://git.kernel.org/stable/c/d9e47e29aacb9f8a9d59feb6ab5b128a9bbb40b0
- https://git.kernel.org/stable/c/f99ac36b5d7c719d08a69fcdecce40f78a874e15
- https://git.kernel.org/stable/c/f9ef3db77a383d66847fd082c2b437d8ae4d9c63
- https://git.kernel.org/stable/c/fa6e90bc443bed8dc0d55bc5ea5b27ffdfe37704
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO
nf_osf_match_one() computes ctx->window % f->wss.val in the
OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A
CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a
subsequent matching TCP SYN divides by zero and panics the kernel.
Reject the bogus fingerprint in nfnl_osf_add_callback() above the
per-option for-loop. f->wss is per-fingerprint, not per-option, so
the check must run regardless of f->opt_num (including 0). Also
reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that
as "should not happen".
Crash:
Oops: divide error: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)
Call Trace:
nf_osf_match (net/netfilter/nfnetlink_osf.c:220)
xt_osf_match_packet (net/netfilter/xt_osf.c:32)
ipt_do_table (net/ipv4/netfilter/ip_tables.c:348)
nf_hook_slow (net/netfilter/core.c:622)
ip_local_deliver (net/ipv4/ip_input.c:265)
ip_rcv (include/linux/skbuff.h:1162)
__netif_receive_skb_one_core (net/core/dev.c:6181)
process_backlog (net/core/dev.c:6642)
__napi_poll (net/core/dev.c:7710)
net_rx_action (net/core/dev.c:7945)
handle_softirqs (kernel/softirq.c:622)
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0694618cf3e9b120666e31f5f383a6e466d95a0d
- https://git.kernel.org/stable/c/2195574dc6d9017d32ac346987e12659f931d932
- https://git.kernel.org/stable/c/26900306a5a2c3e4f75c643a064525526bb6e5f3
- https://git.kernel.org/stable/c/8def8fbd23f40e945febe913d04b731012ce0082
- https://git.kernel.org/stable/c/9a05e195618a6d474f2bcd5b6376d0ffc2f00366
- https://git.kernel.org/stable/c/c55940895245d8ef658ab381248a28755218d625
- https://git.kernel.org/stable/c/cb833bbc1b3c51e08652d3c86298307c07d3f2db
- https://git.kernel.org/stable/c/fb965b1cfe92b28d28b5ebe3116b81dbef9f2d2f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
slip: reject VJ receive packets on instances with no rstate array
slhc_init() accepts rslots == 0 as a valid configuration, with the
documented meaning of 'no receive compression'. In that case the
allocation loop in slhc_init() is skipped, so comp->rstate stays
NULL and comp->rslot_limit stays 0 (from the kzalloc of struct
slcompress).
The receive helpers do not defend against that configuration.
slhc_uncompress() dereferences comp->rstate[x] when the VJ header
carries an explicit connection ID, and slhc_remember() later assigns
cs = &comp->rstate[...] after only comparing the packet's slot number
to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the
range check, and the code dereferences a NULL rstate.
The configuration is reachable in-tree through PPP. PPPIOCSMAXCID
stores its argument in a signed int, and (val >> 16) uses arithmetic
shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1
is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because
/dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path
is reachable from an unprivileged user namespace. Once the malformed
VJ state is installed, any inbound VJ-compressed or VJ-uncompressed
frame that selects slot 0 crashes the kernel in softirq context:
Oops: general protection fault, probably for non-canonical
address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519)
Call Trace:
ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466)
ppp_input (drivers/net/ppp/ppp_generic.c:2359)
ppp_async_process (drivers/net/ppp/ppp_async.c:492)
tasklet_action_common (kernel/softirq.c:926)
handle_softirqs (kernel/softirq.c:623)
run_ksoftirqd (kernel/softirq.c:1055)
smpboot_thread_fn (kernel/smpboot.c:160)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:164)
Reject the receive side on such instances instead of touching rstate.
slhc_uncompress() falls through to its existing 'bad' label, which
bumps sls_i_error and enters the toss state. slhc_remember() mirrors
that with an explicit sls_i_error increment followed by slhc_toss();
the sls_i_runt counter is not used here because a missing rstate is
an internal configuration state, not a runt packet.
The transmit path is unaffected: the only in-tree caller that picks
rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and
slip.c always calls slhc_init(16, 16), so comp->tstate remains valid
and slhc_compress() continues to work.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3d71c961febddd855d3ae9a519eeb96c8023f430
- https://git.kernel.org/stable/c/4aa9eca6fda2919027dfd7a7cc69334982d89586
- https://git.kernel.org/stable/c/72304fec672e8aac9ee7b9c475db96b37cca8d8d
- https://git.kernel.org/stable/c/7b0d9e878ec2b21d99ae8051b3dda59cdb66c152
- https://git.kernel.org/stable/c/9e1ff0eead073c4f46d874ad2526b7dda5465faf
- https://git.kernel.org/stable/c/c6980e8b1a86288167f34966fa5219031999b6f1
- https://git.kernel.org/stable/c/de42f86e2cf5028a97e74c25869d1a962b13c301
- https://git.kernel.org/stable/c/e76607442d5b73e1ba6768f501ef815bb58c2c0e
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.
CVSS 3.xВЫСОКАЯ 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:NСсылки
- https://git.kernel.org/stable/c/0511ecb00e61bf28e2fec4bb41fcce385c3a3b2d
- https://git.kernel.org/stable/c/335957df4ed60f02a2ec0432fbedbf0cc7241d8b
- https://git.kernel.org/stable/c/37537e42e6df387398bee85cb85070cc80bb1e10
- https://git.kernel.org/stable/c/4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7
- https://git.kernel.org/stable/c/4cefe32639933d652614b0bd50f818f9af4af78f
- https://git.kernel.org/stable/c/6268f01ae989013671b526c883e92655342c6f6f
- https://git.kernel.org/stable/c/9aafba2f49e1fcccc2018816f5836a609c925879
- https://git.kernel.org/stable/c/d42bec6e4f6d6d658be365539400b3314b76b2a7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
netfilter: arp_tables: fix IEEE1394 ARP payload parsing
Weiming Shi says:
"arp_packet_match() unconditionally parses the ARP payload assuming two
hardware addresses are present (source and target). However,
IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address
field, and arp_hdr_len() already accounts for this by returning a
shorter length for ARPHRD_IEEE1394 devices.
As a result, on IEEE1394 interfaces arp_packet_match() advances past a
nonexistent target hardware address and reads the wrong bytes for both
the target device address comparison and the target IP address. This
causes arptables rules to match against garbage data, leading to
incorrect filtering decisions: packets that should be accepted may be
dropped and vice versa.
The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already
handles this correctly by skipping the target hardware address for
ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."
Mangle the original patch to always return 0 (no match) in case user
matches on the target hardware address which is never present in
IEEE1394.
Note that this returns 0 (no match) for either normal and inverse match
because matching in the target hardware address in ARPHRD_IEEE1394 has
never been supported by arptables. This is intentional, matching on the
target hardware address should never evaluate true for ARPHRD_IEEE1394.
Moreover, adjust arpt_mangle to drop the packet too as AI suggests:
In arpt_mangle, the logic assumes a standard ARP layout. Because
IEEE1394 (FireWire) omits the target hardware address, the linear
pointer arithmetic miscalculates the offset for the target IP address.
This causes mangling operations to write to the wrong location, leading
to packet corruption. To ensure safety, this patch drops packets
(NF_DROP) when mangling is requested for these fields on IEEE1394
devices, as the current implementation cannot correctly map the FireWire
ARP payload.
This omits both mangling target hardware and IP address. Even if IP
address mangling should be possible in IEEE1394, this would require
to adjust arpt_mangle offset calculation, which has never been
supported.
Based on patch from Weiming Shi .
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/03ea11dbefaa55c502735ee551c89ef773fe753b
- https://git.kernel.org/stable/c/0f23a1457695f1a61f64367e39f0f9cfa29947d1
- https://git.kernel.org/stable/c/1c55053f8ffdc060006df898fd3664e3d1bfac7b
- https://git.kernel.org/stable/c/1e285362ef7096eb12733370d59e033f4a1d294a
- https://git.kernel.org/stable/c/1e8e3f449b1e73b73a843257635b9c50f0cc0f0a
- https://git.kernel.org/stable/c/84e8536c981338d0d8cc6e712cf71a936a93e13f
- https://git.kernel.org/stable/c/ac698d81fd6619c7504cee913f1cab5285fba1b7
- https://git.kernel.org/stable/c/ad9973df8e0eeb123d9ec4d18828e05b7d44ff4b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: fix NULL pointer dereference in class dump
When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
Subsequent RTM_GETTCLASS dump operations walk all classes via
taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
returning the NULL pointer, then dereferences it to read child->handle,
causing a kernel NULL pointer dereference.
The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
namespaces enabled, an unprivileged local user can trigger a kernel
panic by creating a taprio qdisc inside a new network namespace,
grafting an explicit child qdisc, deleting it, and requesting a class
dump. The RTM_GETTCLASS dump itself requires no capability.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478)
Call Trace:
tc_fill_tclass (net/sched/sch_api.c:1966)
qdisc_class_dump (net/sched/sch_api.c:2326)
taprio_walk (net/sched/sch_taprio.c:2514)
tc_dump_tclass_qdisc (net/sched/sch_api.c:2352)
tc_dump_tclass_root (net/sched/sch_api.c:2370)
tc_dump_tclass (net/sched/sch_api.c:2431)
rtnl_dumpit (net/core/rtnetlink.c:6864)
netlink_dump (net/netlink/af_netlink.c:2325)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6959)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
Fix this by substituting &noop_qdisc when new is NULL in
taprio_graft(), a common pattern used by other qdiscs (e.g.,
multiq_graft()) to ensure the q->qdiscs[] slots are never NULL.
This makes control-plane dump paths safe without requiring individual
NULL checks.
Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)
previously had explicit NULL guards that would drop/skip the packet
cleanly, update those checks to test for &noop_qdisc instead. Without
this, packets would reach taprio_enqueue_one() which increments the root
qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc
drops the packet but those counters are never rolled back, permanently
inflating the root qdisc's statistics.
After this change *old can be a valid qdisc, NULL, or &noop_qdisc.
Only call qdisc_put(*old) in the first case to avoid decreasing
noop_qdisc's refcount, which was never increased.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3d07ca5c0fae311226f737963984bd94bb159a87
- https://git.kernel.org/stable/c/48b26d48e76221dc90b02bf5428bab53643461ca
- https://git.kernel.org/stable/c/8f1ff8866cb9f655e5faea6994eb902960be8e04
- https://git.kernel.org/stable/c/d02e2fbf60de46678e2ea698a6a904fd21e1cc31
- https://git.kernel.org/stable/c/ec2501e361b08b50bcb1e7b3253fc861abbda28d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
bareudp_fill_metadata_dst() passes bareudp->sock to
udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check.
The socket is only created in bareudp_open() and NULLed in
bareudp_stop(), so calling this function while the device is down
triggers a NULL dereference via sock->sk.
BUG: kernel NULL pointer dereference, address: 0000000000000018
RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160)
Call Trace:
bareudp_fill_metadata_dst (drivers/net/bareudp.c:532)
do_execute_actions (net/openvswitch/actions.c:901)
ovs_execute_actions (net/openvswitch/actions.c:1589)
ovs_packet_cmd_execute (net/openvswitch/datapath.c:700)
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)
genl_rcv_msg (net/netlink/genetlink.c:1209)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths
in the same driver.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/31e010a106ff6cd8ccac4bfee547fd3fa1015574
- https://git.kernel.org/stable/c/35a115a204be08f97450b0389413e218268ef4a2
- https://git.kernel.org/stable/c/51eef9c072aa3405a6823a96ae666d38a3b48750
- https://git.kernel.org/stable/c/55193df8d6d33318435f19572bf5ea47a22eee28
- https://git.kernel.org/stable/c/638905520fc4fae6a80991563f264131545ba3df
- https://git.kernel.org/stable/c/74a02921c48fcd35a7881956c9e5c52b86595f5d
- https://git.kernel.org/stable/c/a0f4e4e8e0f5e24ddd83e3d1221732621cf34636
- https://git.kernel.org/stable/c/aa6c6d9ee064aabfede4402fd1283424e649ca19
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/159f2efabc89d3f931d38f2d35876535d4abf0a3
- https://git.kernel.org/stable/c/9cc0c6b1ba8cd5c55aef043e1384de0a8b4efa71
- https://git.kernel.org/stable/c/9ef65af26b2a6738bf15812042e84b3112402d3a
- https://git.kernel.org/stable/c/db991ba50087ad99fa12a2c483aa3be19671ea73
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:30129
- https://access.redhat.com/errata/RHSA-2026:42550
- https://access.redhat.com/errata/RHSA-2026:42552
- https://access.redhat.com/security/cve/CVE-2026-46117
- https://bugzilla.redhat.com/show_bug.cgi?id=2482576
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46117.json
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/013dcdc1961543b9a3433466bc8c79a2f4ca75b5
- https://git.kernel.org/stable/c/23079e0b7742ec114d3507c3e3aad01b7b69e4af
- https://git.kernel.org/stable/c/2ad56e434199ca24a812bb353667aa1c3860f513
- https://git.kernel.org/stable/c/5cd6e0ad79d2615264f63929f8b457ad97ae550d
- https://git.kernel.org/stable/c/6e4710d7d8782cb61af29a7e7111ddfc38b9e1a3
- https://git.kernel.org/stable/c/b35605e1f1e877038c8c9d499babbc891cdd234f
- https://git.kernel.org/stable/c/cc3c0399361efaaf7ae64262eb3f70829b1189c6
- https://git.kernel.org/stable/c/d9b272a85fe6b8f993e37915311e4038c814a533
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely".
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/25e37407442b8766ec2cf52fb4e31b5c3d3aeeae
- https://git.kernel.org/stable/c/9426265e157dd77ec237c795901ed4dea6d69b5c
- https://git.kernel.org/stable/c/9634cb35af17019baec21ca648516ce376fa10e6
- https://git.kernel.org/stable/c/acd3d3562315c99f3c0db16f0fcc5f0306638982
- https://git.kernel.org/stable/c/b41dd76f3b9735096c21d3e799a2b9fe36498d57
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix missing last_unlink_trans update when removing a directory
When removing a directory we are not updating its last_unlink_trans field,
which can result in incorrect fsync behaviour in case some one fsyncs the
directory after it was removed because it's holding a file descriptor on
it.
Example scenario:
mkdir /mnt/dir1
mkdir /mnt/dir1/dir2
mkdir /mnt/dir3
sync -f /mnt
# Do some change to the directory and fsync it.
chmod 700 /mnt/dir1
xfs_io -c fsync /mnt/dir1
# Move dir2 out of dir1 so that dir1 becomes empty.
mv /mnt/dir1/dir2 /mnt/dir3/
open fd on /mnt/dir1
call rmdir(2) on path "/mnt/dir1"
fsync fd
When attempting to mount the filesystem, the log replay will fail with
an -EIO error and dmesg/syslog has the following:
[445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650
[445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm
[445771.627912] BTRFS info (device dm-0): start tree-log replay
[445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5
[445771.629453] memcg:ffff89f400351b00
[445771.629892] aops:btree_aops [btrfs] ino:1
[445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)
[445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8
[445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00
[445771.635029] page dumped because: eb page dump
[445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir
[445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5
[445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087
[445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
[445771.638097] inode generation 3 transid 9 size 16 nbytes 16384
[445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0
[445771.638100] rdev 0 sequence 2 flags 0x0
[445771.638102] atime 1775744884.0
[445771.660056] ctime 1775744885.645502983
[445771.660058] mtime 1775744885.645502983
[445771.660060] otime 1775744884.0
[445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
[445771.660064] index 0 name_len 2
[445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34
[445771.660068] location key (259 1 0) type 2
[445771.660070] transid 9 data_len 0 name_len 4
[445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34
[445771.660076] location key (257 1 0) type 2
[445771.660077] transid 9 data_len 0 name_len 4
[445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34
[445771.660079] location key (257 1 0) type 2
[445771.660080] transid 9 data_len 0 name_len 4
[445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34
[445771.660082] location key (259 1 0) type 2
[445771.660083] transid 9 data_len 0 name_len 4
[445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160
[445771.660086] inode generation 9 transid 9 size 8 nbytes 0
[445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0
[445771.660088] rdev 0 sequence 2 flags 0x0
[445771.660089] atime 1775744885.641174097
[445771.660090] ctime 1775744885.645502983
[445771.660091] mtime 1775744885.645502983
[445771.660105] otime 1775744885.641174097
[445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14
[445771.660107] index 2 name_len 4
[445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34
[445771.660109] location key (2
---truncated---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2525998ac956476bded26b9f34c4164dc890b87a
- https://git.kernel.org/stable/c/36fcc2c7517f8a86379154c9793f867592aa8b7e
- https://git.kernel.org/stable/c/6acbb2f6dff23c9bb9761fb98b516525b9cf1ce9
- https://git.kernel.org/stable/c/999757231c49376cd1a37308d2c8c4c9932571e1
- https://git.kernel.org/stable/c/aa9c3ecaf7337df3a689318584f879b5339ede0f
- https://git.kernel.org/stable/c/af467162290f5fe79d6a361b7c84302e45b1fd9f
- https://git.kernel.org/stable/c/cc3c0a0f965754ce230d93ba44ee5b34fbe6138a
- https://git.kernel.org/stable/c/fb388eb58c1ba047ccabc33901839acfecadcf49
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself".
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/531c537b8fb620beabccfb1594e8d43cbebbb87a
- https://git.kernel.org/stable/c/6a3af482188f6db4186d1605f64d911d7330abb3
- https://git.kernel.org/stable/c/8143a224785ceaf2b0856e08d4498916f38228fb
- https://git.kernel.org/stable/c/b74ad20198652b6b39a761c277ba65ae82b1e107
- https://git.kernel.org/stable/c/b7b9a461569734d33d3259d58d2507adfac107ed
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()
When media GT is disabled via configfs, there is no allocation for
media_gt, which is kept as NULL. In such scenario,
intel_hdcp_gsc_check_status() results in a kernel pagefault error due to
>->uc.gsc being evaluated as an invalid memory address.
Fix that by introducing a NULL check on media_gt and bailing out early
if so.
While at it, also drop the NULL check for gsc, since it can't be NULL if
media_gt is not NULL.
v2:
- Get address for gsc only after checking that gt is not NULL.
(Shuicheng)
- Drop the NULL check for gsc. (Shuicheng)
v3:
- Add "Fixes" and "Cc: " tags. (Matt)
(cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NСсылки
- https://git.kernel.org/stable/c/0aece6685fc80a8de492688ca2315fb86ec379c7
- https://git.kernel.org/stable/c/2035acfb17221729b1b8ac335e941868a04ca079
- https://git.kernel.org/stable/c/3da1fdf4efbc490041eb4f836bf596201203f8f2
- https://git.kernel.org/stable/c/7713bd320ed4fc3d08a227cd8e41242219a16981
- https://git.kernel.org/stable/c/91f89c1d83e80417629791fcef6af8140d7d01c8
- https://git.kernel.org/stable/c/9544559e59438a4b609b2fdfa0763d8360572824
- https://git.kernel.org/stable/c/a3bbda6502a9398b816fa2e71c9a3f955f58013d
- https://git.kernel.org/stable/c/cf20038657d6d4974349556a34e08fe0490bebbc
- http://www.openwall.com/lists/oss-security/2026/06/01/6
- https://access.redhat.com/errata/RHSA-2026:23258
- https://access.redhat.com/errata/RHSA-2026:23259
- https://access.redhat.com/errata/RHSA-2026:23329
- https://access.redhat.com/errata/RHSA-2026:23395
- https://access.redhat.com/errata/RHSA-2026:24381
- https://access.redhat.com/errata/RHSA-2026:25908
- https://access.redhat.com/errata/RHSA-2026:26462
- https://access.redhat.com/errata/RHSA-2026:26515
- https://access.redhat.com/errata/RHSA-2026:26535
- https://access.redhat.com/errata/RHSA-2026:26563
- https://access.redhat.com/errata/RHSA-2026:26570
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27719
- https://access.redhat.com/errata/RHSA-2026:27729
- https://access.redhat.com/errata/RHSA-2026:27735
- https://access.redhat.com/errata/RHSA-2026:28887
- https://access.redhat.com/errata/RHSA-2026:28962
- https://access.redhat.com/errata/RHSA-2026:33219
- https://access.redhat.com/errata/RHSA-2026:33220
- https://access.redhat.com/errata/RHSA-2026:33221
- https://access.redhat.com/errata/RHSA-2026:33222
- https://access.redhat.com/errata/RHSA-2026:33223
- https://access.redhat.com/errata/RHSA-2026:33224
- https://access.redhat.com/errata/RHSA-2026:33225
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/errata/RHSA-2026:34048
- https://access.redhat.com/errata/RHSA-2026:34757
- https://access.redhat.com/errata/RHSA-2026:34764
- https://access.redhat.com/errata/RHSA-2026:34788
- https://access.redhat.com/errata/RHSA-2026:34815
- https://access.redhat.com/errata/RHSA-2026:36620
- https://access.redhat.com/errata/RHSA-2026:40021
- https://access.redhat.com/errata/RHSA-2026:41236
- https://access.redhat.com/errata/RHSA-2026:47727
- https://access.redhat.com/security/cve/CVE-2026-46243
- https://bugzilla.redhat.com/show_bug.cgi?id=2481486
- https://github.com/manizada/CIFSwitch
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46243.json
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: Fix IPv6 inner_thoff desync In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2. For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.
CVSS 3.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NСсылки
- https://git.kernel.org/stable/c/689bbf48c1f45130086ae1c46ab83ea4c753c601
- https://git.kernel.org/stable/c/870d59e2cf218e7418491e26bad768cb16654582
- https://git.kernel.org/stable/c/b6a91f68ebfed9c38e0e9150f58a9b85da07181c
- https://git.kernel.org/stable/c/c161ad9157f5a0429b5ff94d9770faf3bf48d273
- https://git.kernel.org/stable/c/d0f98a3617f6ae5b1e95cde1e68e7ead4a1279ce
- https://access.redhat.com/errata/RHSA-2026:33215
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/errata/RHSA-2026:34443
- https://access.redhat.com/errata/RHSA-2026:34911
- https://access.redhat.com/errata/RHSA-2026:36018
- https://access.redhat.com/security/cve/CVE-2026-46244
- https://bugzilla.redhat.com/show_bug.cgi?id=2484451
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46244.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/252c5051dba9c709b6a72f2866f93e5e618b3f06
- https://git.kernel.org/stable/c/5a20ebf0c81b61f5ea3b1b529c100cad69b9f603
- https://git.kernel.org/stable/c/d376c131af7c7739a87ff037ed2fdb67c2542c8a
- https://git.kernel.org/stable/c/d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc
- https://git.kernel.org/stable/c/d6bda9df0c0a3080804181464d5c0f4d78a4e769
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894
- https://git.kernel.org/stable/c/7338031946bd06f6dff149e67b60c4cd083bfea8
- https://git.kernel.org/stable/c/78aad93e938f013d9272fe0ee168f27883afa95c
- https://git.kernel.org/stable/c/81c7a3c22a0f2808cf4ae0b4908f59763b23606d
- https://git.kernel.org/stable/c/9d20d48be2c4a071fb015eb09bda2cecd25daf34
- https://git.kernel.org/stable/c/c1bb9336ae6b54a5f6a353c4bd4ed9a4307e429b
- https://git.kernel.org/stable/c/c85cff648a2bc92322912db5f1727ad05afae7b6
- https://git.kernel.org/stable/c/e2d19969c8d9198ecc3090bcd5312ecd503a3339
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c
- https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987
- https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111
- https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a
- https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e
- https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0
- https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5
- https://git.kernel.org/stable/c/f84eca5817390257cef78013d0112481c503b4a3
- http://www.openwall.com/lists/oss-security/2026/05/13/5
- http://www.openwall.com/lists/oss-security/2026/05/21/11
- http://www.openwall.com/lists/oss-security/2026/05/21/12
- http://www.openwall.com/lists/oss-security/2026/05/21/13
- https://access.redhat.com/errata/RHBA-2026:20032
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:19540
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19664
- https://access.redhat.com/errata/RHSA-2026:19666
- https://access.redhat.com/errata/RHSA-2026:19705
- https://access.redhat.com/errata/RHSA-2026:19711
- https://access.redhat.com/errata/RHSA-2026:19875
- https://access.redhat.com/errata/RHSA-2026:20051
- https://access.redhat.com/errata/RHSA-2026:20054
- https://access.redhat.com/errata/RHSA-2026:20087
- https://access.redhat.com/errata/RHSA-2026:20129
- https://access.redhat.com/errata/RHSA-2026:20130
- https://access.redhat.com/errata/RHSA-2026:20299
- https://access.redhat.com/errata/RHSA-2026:20593
- https://access.redhat.com/errata/RHSA-2026:21656
- https://access.redhat.com/errata/RHSA-2026:21690
- https://access.redhat.com/errata/RHSA-2026:21695
- https://access.redhat.com/errata/RHSA-2026:21702
- https://access.redhat.com/errata/RHSA-2026:23233
- https://access.redhat.com/errata/RHSA-2026:23240
- https://access.redhat.com/errata/RHSA-2026:23245
- https://access.redhat.com/errata/RHSA-2026:23468
- https://access.redhat.com/errata/RHSA-2026:23469
- https://access.redhat.com/errata/RHSA-2026:23470
- https://access.redhat.com/errata/RHSA-2026:23471
- https://access.redhat.com/errata/RHSA-2026:24814
- https://access.redhat.com/errata/RHSA-2026:25044
- https://access.redhat.com/errata/RHSA-2026:28887
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/errata/RHSA-2026:34098
- https://access.redhat.com/security/cve/CVE-2026-46300
- https://bugzilla.redhat.com/show_bug.cgi?id=2477015
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://cert-portal.siemens.com/productcert/html/ssa-082556.html
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46300.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: clear waitid info before copying it to userspace IORING_OP_WAITID stores its result fields in struct io_waitid::info and later copies them to userspace siginfo. The prep path initializes the request arguments, but it does not initialize info itself. If the wait operation completes without reporting a child event, the common wait code can return without writing wo_info. In that case io_waitid_finish() still copies iw->info to userspace, exposing stale bytes from the reused io_kiocb command storage. Clear the result storage during prep so the io_uring path matches the regular waitid syscall, which uses a zero-initialized struct waitid_info.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/17dfb67cb399b660105d9a8c6100851c0d0cdc70
- https://git.kernel.org/stable/c/3e20e1b3058e0b94638e7b931c138e840e266724
- https://git.kernel.org/stable/c/4c727c6967a41b37efe0f26332ca9ec5b74785a3
- https://git.kernel.org/stable/c/67c9ecc9f2575273ed1323e312881fc98ac83d6d
- https://git.kernel.org/stable/c/a2e0c045c87aa252eb61412e67dd91f2c2b19f81
- https://git.kernel.org/stable/c/ece578ca61e572df96cfc80456357ebfae0b4b9e
- https://git.kernel.org/stable/c/f23424a0ddadb494d4bd57056a7ca703312d3a7b
- https://git.kernel.org/stable/c/f462dca0c8415bf0058d0ffa476354c4476d0f09
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: gro: don't merge zcopy skbs skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag. When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF. When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1f9c828556416fbe3f49386708ce999fc4d4da06
- https://git.kernel.org/stable/c/3c6cc9f2ca65b6dd61b1af75452dc0e1cd0aad8d
- https://git.kernel.org/stable/c/44bea2032af0425e4ce6d26a8af0ede79db49ec1
- https://git.kernel.org/stable/c/479084ae0e1d9cb7929cb4298d35623de189f80a
- https://git.kernel.org/stable/c/4db79a322db8c97f7b73b8a347395ef4d685eb40
- https://git.kernel.org/stable/c/e334cbf3388fd9334503a778a82d9e9f14dd2f71
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27731
- https://access.redhat.com/errata/RHSA-2026:27735
- https://access.redhat.com/errata/RHSA-2026:36018
- https://access.redhat.com/errata/RHSA-2026:44230
- https://access.redhat.com/errata/RHSA-2026:44231
- https://access.redhat.com/errata/RHSA-2026:44259
- https://access.redhat.com/errata/RHSA-2026:44262
- https://access.redhat.com/errata/RHSA-2026:44270
- https://access.redhat.com/errata/RHSA-2026:47727
- https://access.redhat.com/security/cve/CVE-2026-46323
- https://bugzilla.redhat.com/show_bug.cgi?id=2479832
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46323.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: scope conn->binding slowpath to bound sessions only When the binding SESSION_SETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbd_session_lookup_all() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked. Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbd_chann_list). The channel entry is installed by the existing binding_session path in ntlm_authenticate()/krb5_authenticate() when a SESSION_SETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table. The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1e2bec062c5c9ec282636715166056d0998d746d
- https://git.kernel.org/stable/c/1ff46c9915c1cbf454db58a8cb87f7cac818e6a6
- https://git.kernel.org/stable/c/2cc8a4db633b10715450b291c1343859a4b2c509
- https://git.kernel.org/stable/c/974c1c224e85549dc3459f3bb2255bbbdd2b9372
- https://git.kernel.org/stable/c/b0da97c034b6107d14e537e212d4ce8b22109a58
- https://git.kernel.org/stable/c/e3a93ce6e25757b8f375e38b8f91e1d9da4edc1a
- https://git.kernel.org/stable/c/e74c00c6af428a39e564cdc5bd3a3648c6d8de87
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: hold bridge skb->dev while queued br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCAL_IN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection. When the verdict is reinjected later, br_netif_receive_skb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free. Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEV_DOWN handling.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/15d464265120ab9818bd673af301deee09bedab2
- https://git.kernel.org/stable/c/19924bdd8a45ebc72a7b84c57fd63057d1dc75ac
- https://git.kernel.org/stable/c/1e5e20031c5eee8d2e490a90ff4d6a2feecfc3be
- https://git.kernel.org/stable/c/3823c27099cfe2482299065814adbaa771be9644
- https://git.kernel.org/stable/c/3fb0f5c0f64162a8c3f25616a4f1e340b921737f
- https://git.kernel.org/stable/c/950d809f154dca04e5fbe5d3c8b9c5e44769cd57
- https://git.kernel.org/stable/c/a698ac8ab2561cf575d2d9f34095032651dd952e
- https://git.kernel.org/stable/c/e196115ec330a18de415bdb9f5071aa9f08e53ce
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix fragment reassembly length accounting batman-adv keeps a running payload length for queued fragments and uses it to validate a fragment chain before reassembly. That accounting currently allows the accumulated fragment length to be truncated during updates. As a result, malformed fragment chains can bypass the intended validation and drive reassembly with inconsistent length state, leading to a local denial of service. Fix the accounting by storing the accumulated length in a length-typed field and rejecting update overflows before the existing validation logic runs. The fix was verified against the original reproducer and against valid fragment reassembly paths.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/37be61825b15534a16ff9cfc9546de155b6df982
- https://git.kernel.org/stable/c/3eb8bcb823391bd58997831b3c9c152a4ba8e255
- https://git.kernel.org/stable/c/975563c5de1123dde1ec7946bf5556d20c89d74e
- https://git.kernel.org/stable/c/9cd3f16c320bfdadd4509358122368deb56a5741
- https://git.kernel.org/stable/c/e4f3f6b818aa6a678bc54a2d4e0bece2303c6a64
- https://git.kernel.org/stable/c/e910dbf509125fe51ad68e4fa74dc8ab0a8e787a
- https://git.kernel.org/stable/c/f653b040dad1af70fa5cd4fe085e4758925480c9
- https://git.kernel.org/stable/c/fdb2c96efb2baeb3725e9ce3ede8f1e36f5490f0
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_hbh: reject oversized option lists struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors, but hbh_mt6_check() does not reject larger optsnr values supplied from userspace. Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged. `struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array, where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible: [ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]'
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2d523ba48d4ecc46acfb6aba548292cfcce1ac02
- https://git.kernel.org/stable/c/41ec2e242f1702e8370ddfe14d22b7a766021c3e
- https://git.kernel.org/stable/c/4322dcde6b4173c2d8e8e6118ed290794263bcc8
- https://git.kernel.org/stable/c/57b0ac5e1b46f1f0338dff392ef2092e2871b412
- https://git.kernel.org/stable/c/588933f1a2ca5ff99274f8c9f25dc3a25d0191c3
- https://git.kernel.org/stable/c/6feb43c0995ab3a9c826707eb46541a1696fe4f7
- https://git.kernel.org/stable/c/784aadea7a108c9f90985683caa87fb0198c6a39
- https://git.kernel.org/stable/c/db0250470f023f159094052c0bd5ab026a88ae93
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: disallow unicast fragment in fragment batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a BATADV_UNICAST_FRAG packet is received. Once all fragments are collected and the packet is reassembled, batadv_recv_frag_packet() calls batadv_batman_skb_recv() again to process the defragmented payload. A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting). Each nesting level recurses through batadv_batman_skb_recv() without bound, growing the kernel stack until it is exhausted. Since refragmentation or fragments in fragments are not actually allowed, discard all packets which are still BATADV_UNICAST_FRAG packets after the defragmentation process.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0c208fa3859e3a33a1c38bebc41d021166e94ac8
- https://git.kernel.org/stable/c/5418be6c2e117bf8a316582795a8e3ff90f45e5d
- https://git.kernel.org/stable/c/5895ad21c7059a652da83fb817510f7a1e962abf
- https://git.kernel.org/stable/c/7138c35c9ad39a2fca6264af6b87466471f04ffc
- https://git.kernel.org/stable/c/aea54d0bbe156d5ab7d00d68f66149ff41f4612a
- https://git.kernel.org/stable/c/b54e459cf86943583c1aa2ee3081874e7ab1f5f3
- https://git.kernel.org/stable/c/bc62216dc8e221e3781afa14430f45208bfa9af9
- https://git.kernel.org/stable/c/bcda4814dc6524283c0b958882cb963d75fe411d
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/41c8c1c7923e86e0eb59cfb4279349112756a336
- https://git.kernel.org/stable/c/4ec17782fd186f901a7329605d11048b085b945a
- https://git.kernel.org/stable/c/85f8674cae82053f1e6bab295f6a8422cca14db5
- https://git.kernel.org/stable/c/8b4c412e001b0c670eb937beab491af974da55b3
- https://git.kernel.org/stable/c/a218bf69eb51fefe59a3976fa8925261141f681c
- https://git.kernel.org/stable/c/be43e6b4043113c3b3cf887c3c8350f67140274c
- https://git.kernel.org/stable/c/d9ce4de05df2385c19e2c7d12f529144e1a44af1
- https://git.kernel.org/stable/c/e83f5e24da741fa9405aeeff00b08c5ee7c37b88
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix tp_meter counter underflow during shutdown batadv_tp_sender_shutdown() unconditionally decrements the "sending" atomic counter. If multiple paths (e.g. timeout, user cancel, and normal finish) call this function, the counter can underflow to -1. Since the sender logic treats any non-zero value as "still sending", a negative value causes the sender kthread to loop indefinitely. This leads to a use-after-free when the interface is removed while the zombie thread is still active. Fix this by using atomic_xchg() to ensure the counter only transitions from 1 to 0 once. [sven: added missing change in batadv_tp_send]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/01cefc5923889e29dbb5f281c3d457714ceb9c00
- https://git.kernel.org/stable/c/90ae3eae06b7b8ab9f6250b9497c860915b4c17b
- https://git.kernel.org/stable/c/94f3b133168d1c49895e7cc6afbcf1cc0b354602
- https://git.kernel.org/stable/c/abae88fa254f2981d39ac003a7b302528a22af64
- https://git.kernel.org/stable/c/aeae11c5dad9cd0d50723890bdd866f8e6db2e7d
- https://git.kernel.org/stable/c/c1bac194733aabd731aafa6a01350c229e187dba
- https://git.kernel.org/stable/c/c66d20a3ff095e3f000551d208ec2606616db15c
- https://git.kernel.org/stable/c/e75e2ab463b5b34df6b98f94d740aff327ce9f6b
HIGH8.3
In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_policy: fix strict mode inbound policy matching match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout. Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently.
CVSS 3.xВЫСОКАЯ 8.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:HСсылки
- https://git.kernel.org/stable/c/392cc1d8408b5665215c1e9290bbf0f92339b043
- https://git.kernel.org/stable/c/4b2b4d7d4e203c92db8966b163edfacb1f0e1e29
- https://git.kernel.org/stable/c/82664d0f1ba25e4f9a71994954abae24c60f4067
- https://git.kernel.org/stable/c/938867e870fb5471bb16f442aeac81326e05bf65
- https://git.kernel.org/stable/c/b130a6eefa02bd4d475f2f059da8bcfb3e7d18d9
- https://git.kernel.org/stable/c/eb323f7b82d2e2f638de0cc2a177803eb20e0707
- https://git.kernel.org/stable/c/f98b7f85e04b40e28b08c461ded0cc79f14f5509
- https://git.kernel.org/stable/c/fc1c518bb1f054831ecabb32da9b8e1dff9699c6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: stop hash:* range iteration at end The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/02f75f041a93ea045834da89cd3234f4c1d749b4
- https://git.kernel.org/stable/c/0b530efb2cc9dbdddfd49d392e3a857f0d4ce8dc
- https://git.kernel.org/stable/c/0d3a282ab5f165fc207ff49ea5b6ad8f54616bd6
- https://git.kernel.org/stable/c/0d7b33ace701fe397e6e4de145f32e098178d901
- https://git.kernel.org/stable/c/383418c20e69f5761b6ec5238f599423f4fb77fb
- https://git.kernel.org/stable/c/952e988163c2ab9939c3db9f0f8e77af6a1bb436
- https://git.kernel.org/stable/c/be75218fadea22e59c8673db212f29c681bf45bb
- https://git.kernel.org/stable/c/c281e018af98df91827d65bec00f4956c00a1b02
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: handle forward allocation error batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb for each DHT candidate, but does not check the return value before passing it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences the skb unconditionally, so a failed allocation triggers a NULL pointer dereference. Skip forwarding to the current DHT candidate on allocation failure.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2d8826a2d3657cea66fb0370f9e521575a673871
- https://git.kernel.org/stable/c/2edb8aeb3cdda9d00ec4997252dc5bcd6f54d8ef
- https://git.kernel.org/stable/c/4d420d9ee70a220a2cd95aa0dd2e15acad66a505
- https://git.kernel.org/stable/c/866ac1d57040ed0b44ca732e3c66b3aa6b93011c
- https://git.kernel.org/stable/c/9bcebaedfb8479cb4affb23c7a0d000ca9a20e73
- https://git.kernel.org/stable/c/9cceea8eeba710def2a5707ee00f00c74a9a1cac
- https://git.kernel.org/stable/c/ce0c381199402a2c58f4599f4f6ed100d872d0da
- https://git.kernel.org/stable/c/cf48e75fc4fe0d5cc7721c82d454221d01367b93
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
vrf: Fix a potential NPD when removing a port from a VRF
RCU readers that identified a net device as a VRF port using
netif_is_l3_slave() assume that a subsequent call to
netdev_master_upper_dev_get_rcu() will return a VRF device. They then
continue to dereference its l3mdev operations.
This assumption is not always correct and can result in a NPD [1]. There
is no RCU synchronization when removing a port from a VRF, so it is
possible for an RCU reader to see a new master device (e.g., a bridge)
that does not have l3mdev operations.
Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE
flag. Skip this synchronization when a net device is removed from a VRF
as part of its deletion and when the VRF device itself is deleted. In
the latter case an RCU grace period will pass by the time RTNL is
released.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181)
[...]
Call Trace:
l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189)
__inet_bind (net/ipv4/af_inet.c:499 (discriminator 3))
inet_bind_sk (net/ipv4/af_inet.c:469)
__sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1))
__x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1))
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2674d603a9e6970463b2b9ebcf8e31e90beae169
- https://git.kernel.org/stable/c/2c022f582fd16a470df6ed9e7fb7e9fc48946d49
- https://git.kernel.org/stable/c/3db8d078f7f652379ee394132b169d304f6eb4c1
- https://git.kernel.org/stable/c/468defa0b70902a22f4478c1207624bc1b31c124
- https://git.kernel.org/stable/c/4ab6fc60ed5a0344b60711b09bff1dc238d8d6a4
- https://git.kernel.org/stable/c/8c2b792f04a3db97c9d8d2a45817e93f8884baf5
- https://git.kernel.org/stable/c/a7a97f2303e63ede105c1d55ef53dc497364e11d
- https://git.kernel.org/stable/c/d47204c127992da0c976ac9747070a575912e0fe
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: clear current gateway during teardown batadv_gw_node_free() removes the gateway list entries during mesh teardown, but it does not clear the currently selected gateway. This leaves stale gateway state behind across cleanup and can break a later mesh recreation. Clear bat_priv->gw.curr_gw before walking the gateway list so the selected gateway reference is dropped as part of teardown.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/17e3a441111cd1a530cd6ee69a22f3161d80d810
- https://git.kernel.org/stable/c/30bda3ef4b0cac777f1a7c314cd08b8ff6437365
- https://git.kernel.org/stable/c/6de089b545db013433cf934bb4e4433dec2dd65f
- https://git.kernel.org/stable/c/9a1a8ed4facfe843bde6fdfcf7af0e9923eb2e17
- https://git.kernel.org/stable/c/a340a51ed801eab7bb454150c226323b865263cc
- https://git.kernel.org/stable/c/a3f3f1ec8aad84c5dd386c430b9c61cddd85b18f
- https://git.kernel.org/stable/c/ae7aeb0ce3c0ebbe357ed525779acac197a18086
- https://git.kernel.org/stable/c/e2ec4c712d19141ca7bf7fbbb1d842f73abaa186
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid use of uninit sender vars batadv_tp_recv_ack() and batadv_tp_stop() are only valid for tp_vars in the BATADV_TP_SENDER role. When called with a BATADV_TP_RECEIVER role, it proceeds to read sender-only members that were never initialized, leading to undefined behavior. This can be triggered when a node that is currently acting as a receiver in an ongoing tp_meter session receives a malicious ACK packet. Guard against this by checking tp_vars->role immediately after the lookup and bailing out if it is not BATADV_TP_SENDER, before any of those members are accessed.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0e388af04b3958b178a1b979527f93eb46ea1fee
- https://git.kernel.org/stable/c/1a21c055f66e78973712a4a1be2a554f1ee2e4f4
- https://git.kernel.org/stable/c/53f931e0146ae5bdab4cba302646827d06b3794b
- https://git.kernel.org/stable/c/6c65cf23d4c6170fcf5714c32aa64689718cb142
- https://git.kernel.org/stable/c/85397e48afe6be83ffca5ad3f4792296bfc81d3d
- https://git.kernel.org/stable/c/9884c9c02d3c90e9215db3c5128f59045d20ae91
- https://git.kernel.org/stable/c/dc2ae5fbd2dadc26735092f140b246841d969a11
- https://git.kernel.org/stable/c/ecdaa3e4d91040206afe21bc8a0d1198a0971ff3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: jitterentropy - replace long-held spinlock with mutex jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/01d798e9feb30212952d4e992801ba6bd6a82351
- https://git.kernel.org/stable/c/18216b8ab6904753eaf31baf453cb02ecd202ba4
- https://git.kernel.org/stable/c/4c03e6eb98443dc4d6d422a9780034a5b75376b4
- https://git.kernel.org/stable/c/ec427dc5286da1ed08f2d510e2147a7581b0cb02
- https://git.kernel.org/stable/c/ff734dbd9e2432601a6dcd167cfb0bf8a36d1880
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname) conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on these paths already handles this (e.g. !conn->lnk in SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first sendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64 The faulting address 0x3e0 is offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref. Enabling the tracepoint requires root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has no capability check, and SMC-D negotiation needs no admin step on s390 or on x86 with the loopback ISM device loaded. Log an empty device name for SMC-D instead of dereferencing NULL.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/561cf66fa9b6c86dfe4e687d2d1aeaaa6739917f
- https://git.kernel.org/stable/c/68200112534bb2acd1d7117dc2d5c124868d866d
- https://git.kernel.org/stable/c/720c76b930c52cd58f50eb6b10569d03dccc7959
- https://git.kernel.org/stable/c/7bf563badd37cb796df5477d2b78bb64148a1268
- https://git.kernel.org/stable/c/b706d6d76a2a2793fe5ad0fbc2a75b6a460094ef
- https://git.kernel.org/stable/c/d2ea0b8aef8746e147602eac87ca8538f4bc7e66
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: handle empty bo and UAF races There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/20a99ea1e2fd720856d6ba497ff26b82c604751f
- https://git.kernel.org/stable/c/981bedbbe61364fcc3a3b87ebaf648a66cd07108
- https://git.kernel.org/stable/c/9894731e513019df22a29e5c52f1c98890355ff1
- https://git.kernel.org/stable/c/c473ae25421fddc3dde247ba7b85225b10641d09
- https://access.redhat.com/security/cve/CVE-2026-52951
- https://bugzilla.redhat.com/show_bug.cgi?id=2492353
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52951.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: libceph: handle rbtree insertion error in decode_choose_args() A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ]
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a1265a9ab875f92b6a3ffb497404f46cf9d76a3
- https://git.kernel.org/stable/c/0b6a3bcb91bc5bfeda39f0df3b71bab62c13e9da
- https://git.kernel.org/stable/c/4d2b37abda9536808655830d683dc491d31741a8
- https://git.kernel.org/stable/c/534ebc08df97c47d4c7596f336fa31ecbf91519c
- https://git.kernel.org/stable/c/80c73bd1b2b04355d1d0c29be8ccbd25a380905d
- https://git.kernel.org/stable/c/c7bf7864e2924fa5508ac270b0e9364bc13d5a6c
- https://git.kernel.org/stable/c/d289478cfc0bcf81c7914200d6abdcb78bd04ded
- https://git.kernel.org/stable/c/f47430fc1f815e87406e2d3b4e476eff1bc7fd9b
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in crush_decode() A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0f3604cbe4df14c5e58288ac9f57511e726a222d
- https://git.kernel.org/stable/c/3f42508191e129ee6b5ea96578d5cab14f2a013a
- https://git.kernel.org/stable/c/4c79fc2d598694bda845b46229c9d48b65042970
- https://git.kernel.org/stable/c/6e70ef53e818c53eab28d7b0026b7fd03dddaba5
- https://git.kernel.org/stable/c/cceb10023e76bc89f3fe9238ebd0ccab0fc7c7c5
- https://git.kernel.org/stable/c/ea0d42137f0c06da71e37ffc647aab4c5309599a
- https://git.kernel.org/stable/c/ebe76d58a48a48031b98543d86c4cd30a825b622
- https://git.kernel.org/stable/c/fb176a99e4c1a5a8448a83d83d3606203ba81faa
- https://access.redhat.com/security/cve/CVE-2026-52955
- https://bugzilla.redhat.com/show_bug.cgi?id=2492328
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52955.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential null-ptr-deref in decode_choose_args() A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an array of max_buckets CRUSH buckets is decoded, where some indices may not refer to actual buckets and are therefore set to NULL. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). When decoding a crush_choose_arg_map, a series of choose_args for different buckets is decoded, with the bucket_index being read from the incoming message. It is only checked that the bucket index does not exceed max_buckets, but not that it doesn't point to an index with a NULL bucket. If a (potentially corrupted) message contains a crush_choose_arg_map including such a bucket_index, a null pointer dereference may occur in the subsequent processing when attempting to access the bucket with the given index. This patch fixes the issue by extending the affected check. Now, it is only attempted to access the bucket if it is not NULL.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf
- https://git.kernel.org/stable/c/301286c0ccd37d66b0e40786fd35a4f19cdbd88a
- https://git.kernel.org/stable/c/312ec973efac0efb9b9ed64214235910e9ecbaa8
- https://git.kernel.org/stable/c/7169f326a23d0f547fcd90e68b72fd387622e126
- https://git.kernel.org/stable/c/a20e16ebfe2fa65348eb4b2dc7deac330ce03e9c
- https://git.kernel.org/stable/c/d55ffad8d422b5d1cc44dad32bd3d25f4471cd9f
- https://git.kernel.org/stable/c/d7a65a34d2453f8cd3e0cc0e1319740af7e24276
- https://git.kernel.org/stable/c/f2f95e6d4b97e70bb876139b0583fc8079983f85
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in osdmap_decode() When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight).
CVSS 3.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0d2dd7e6bb74fd7712aa73457a4a821906c6863a
- https://git.kernel.org/stable/c/35d0ed82d03e5ee77ea4f31f20e29562a7721649
- https://git.kernel.org/stable/c/36a79759a288961b1ff28a68ec2d1f56f6848098
- https://git.kernel.org/stable/c/3f2575bb7f955d42569d96c3e04fa958a0dcf4b4
- https://git.kernel.org/stable/c/48df98d12b15360cd56af5c1f460307b340c1197
- https://git.kernel.org/stable/c/8713bbc4b2b9ad78f803978e54b7e49dd21bd9be
- https://git.kernel.org/stable/c/e7187f33c02488697ec0d01d82bf7a3f8deaba8f
- https://git.kernel.org/stable/c/ee933694645dac062d65fc2743f92bc06fa0db6b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
The generic/642 test-case can reproduce the kernel crash:
[40243.605254] ------------[ cut here ]------------
[40243.605956] kernel BUG at fs/ceph/xattr.c:918!
[40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI
[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)
[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[40243.611820] Workqueue: ceph-msgr ceph_con_workfn
[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0
[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc
[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287
[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000
[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000
[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000
[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000
[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd
[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000
[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0
[40243.627408] Call Trace:
[40243.627839]
[40243.628188] __prep_cap+0x3fd/0x4a0
[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0
[40243.629474] ceph_check_caps+0x46a/0xc80
[40243.630094] ? __lock_acquire+0x4a2/0x2650
[40243.630773] ? find_held_lock+0x31/0x90
[40243.631347] ? handle_cap_grant+0x79f/0x1060
[40243.632068] ? lock_release+0xd9/0x300
[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340
[40243.633429] ? lock_release+0xd9/0x300
[40243.634052] handle_cap_grant+0xcf6/0x1060
[40243.634745] ceph_handle_caps+0x122b/0x2110
[40243.635415] mds_dispatch+0x5bd/0x2160
[40243.636034] ? ceph_con_process_message+0x65/0x190
[40243.636828] ? lock_release+0xd9/0x300
[40243.637431] ceph_con_process_message+0x7a/0x190
[40243.638184] ? kfree+0x311/0x4f0
[40243.638749] ? kfree+0x311/0x4f0
[40243.639268] process_message+0x16/0x1a0
[40243.639915] ? sg_free_table+0x39/0x90
[40243.640572] ceph_con_v2_try_read+0xf58/0x2120
[40243.641255] ? lock_acquire+0xc8/0x300
[40243.641863] ceph_con_workfn+0x151/0x820
[40243.642493] process_one_work+0x22f/0x630
[40243.643093] ? process_one_work+0x254/0x630
[40243.643770] worker_thread+0x1e2/0x400
[40243.644332] ? __pfx_worker_thread+0x10/0x10
[40243.645020] kthread+0x109/0x140
[40243.645560] ? __pfx_kthread+0x10/0x10
[40243.646125] ret_from_fork+0x3f8/0x480
[40243.646752] ? __pfx_kthread+0x10/0x10
[40243.647316] ? __pfx_kthread+0x10/0x10
[40243.647919] ret_from_fork_asm+0x1a/0x30
[40243.648556]
[40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore
[40243.654766] ---[ end trace 0000000000000000 ]---
Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS
maximum xattr size") moved the required_blob_size computation to before
the __build_xattrs() call, introducing a race.
__build_xattrs() releases and reacquires i_ceph_lock during execution.
In that window, handle_cap_grant() may update i_xattrs.blob with a
newer MDS-provided blob and bump i_xattrs.version. When
__bui
---truncated---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ceph: fix a buffer leak in __ceph_setxattr() The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/3fa13ceefbc5f36131110342743994cb3de80637
- https://git.kernel.org/stable/c/4bfdcefdaa6092a06cacd59389c7756b36e6de8c
- https://git.kernel.org/stable/c/521e5aba857fd267624892c8dd6295f22ce0267e
- https://git.kernel.org/stable/c/5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e
- https://git.kernel.org/stable/c/7d3e8d2d648d5f0df29b4710246680f47695fe94
- https://git.kernel.org/stable/c/bc7abce4460e490dcb579eec770f175b150b685f
- https://git.kernel.org/stable/c/d0cb994605c84a159c1d00d72cdc8583c321ef95
- https://git.kernel.org/stable/c/ecf94823c5c6a20790bb76ed2816822b0beb0c22
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI endpoint descriptor scans snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/09141583bd97f4bbd7358e29fd138fe798467cdb
- https://git.kernel.org/stable/c/3d3b2b01a3e73828e201ece96f863e7a3e0cdc6e
- https://git.kernel.org/stable/c/728ab0c72e49ca27185067984cd565425eb69b2e
- https://git.kernel.org/stable/c/a0226560540c16717efcceaf15c862cf115b01d3
- https://git.kernel.org/stable/c/c59159ce10e75b568cd0d4b29efcb0fb0ddecc94
- https://git.kernel.org/stable/c/c65b137d351e21cbc5630e73ef0eb1e1d75f5b20
- https://git.kernel.org/stable/c/d6854daa67be623860f4e1873fd3d3c275aba4ed
- https://git.kernel.org/stable/c/e2f1260a056eb3215c13c48c5378f3e4112dc3af
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/17e76b19de1aff5ff4de64d269290bd1b07a01d3
- https://git.kernel.org/stable/c/918be519c7876329e1b6e2ea1c59f0b75e792dca
- https://git.kernel.org/stable/c/a310b4bebda5e4a1b26520c0cc5145ccd6d617e2
- https://git.kernel.org/stable/c/f9c184a83574549a36ea69b755f650e57d164c78
- https://git.kernel.org/stable/c/fafc97bd01e4c737eaeafadfdadb1af4bbfa7307
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: smb/client: fix possible infinite loop and oob read in symlink_data() On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1b9331b16b0ed9414dcf7583d8134bdfeb117aae
- https://git.kernel.org/stable/c/1cfa2d59f669db28d6292d10ff87ca6837c781b0
- https://git.kernel.org/stable/c/7d9a7f1f96cd617ee9e75bb22217c709038e26b8
- https://git.kernel.org/stable/c/97a05b0ae9ea5ec052be2eef0f9cc7ce03501bbb
- https://git.kernel.org/stable/c/b41598bf54b3fe528994e573df6008f8f4d0a4f4
- https://git.kernel.org/stable/c/cd4b9b662f0fb9aa97ee6bf9034eca76fc6cab23
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/11b8ff5b930b351dd1f6f088dce0beb027ac92d0
- https://git.kernel.org/stable/c/16d990a15491cf76cd6eef0846e1b4100e63261a
- https://git.kernel.org/stable/c/31a9d9f9942885aae356a1a57c79e82c5b5b0828
- https://git.kernel.org/stable/c/a99a25db131ece5e6c0f7632da606de631efe4f2
- https://git.kernel.org/stable/c/b22a2da8792a7bfe743c1a922e77fa499ddedbe8
- https://git.kernel.org/stable/c/e7216651b94e92e5433fb2f54b77864642b4ea48
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: KVM: Reject wrapped offset in kvm_reset_dirty_gfn() kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/01b71b930f15728aa8599478a7ce90c19dcd9fc2
- https://git.kernel.org/stable/c/0d419c23bb11b5c9664de777c47c1f04a235882d
- https://git.kernel.org/stable/c/0eb281eb95b2d4eea4db1da5fe91023aecc97095
- https://git.kernel.org/stable/c/577a8d3bae0531f0e5ccfac919cd8192f920a804
- https://git.kernel.org/stable/c/74f1a22f7a80f03d28ad8551a2d25d563433addf
- https://git.kernel.org/stable/c/b315b033a877b1ee6d827810b5d7bb4392ffcf8d
- https://git.kernel.org/stable/c/ecf9b3ea7847fe14f34b8c41f00de1eb95c747da
- https://access.redhat.com/security/cve/CVE-2026-52969
- https://bugzilla.redhat.com/show_bug.cgi?id=2492434
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52969.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix missing expect put in obj eval nft_ct_expect_obj_eval() allocates an expectation and may call nf_ct_expect_related(), but never drops its local reference. Add nf_ct_expect_put(exp) before return to balance allocation.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/19f94b6fee75b3ef7fbc06f3745b9a771a8a19a4
- https://git.kernel.org/stable/c/1dced0725e2fae3ac3416274db20a7ff5a46931d
- https://git.kernel.org/stable/c/26ab32ec73941871c97562ee1f39587950dc3b68
- https://git.kernel.org/stable/c/2aef1b13d5c0285f340512c6c07eb858fd018fd8
- https://git.kernel.org/stable/c/7b96242ceedfe249f158419f3254bcee04173ffe
- https://git.kernel.org/stable/c/84c422cea5a45fe56be839f25880f21fd33940cd
- https://git.kernel.org/stable/c/cdb9a25dd3416d427e8b2753210f8baf44207577
- https://git.kernel.org/stable/c/ecca618e1e339494911090474ed87742c0f73976
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Cap AEAD AD length to 0x80000000 In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0b3a57d218618cb1cc78ddc9ba02c07de84b46f4
- https://git.kernel.org/stable/c/265ac26d1c5e17b34d497cbda1f754a1ec8552bc
- https://git.kernel.org/stable/c/97948906dc8e0ea84775e03e35b60a2063c70193
- https://git.kernel.org/stable/c/a1c5672faf8e93e38c2deac3979cc767ca5cf918
- https://git.kernel.org/stable/c/a4fe4eb580bbc7439f649a496d4cf38415a4021c
- https://git.kernel.org/stable/c/a9f68d9ed38dd6e5a6c6d75b03d25c1c133e321d
- https://git.kernel.org/stable/c/e4c06479d7059888adf2f22bc1ebcf053bf691a2
- https://git.kernel.org/stable/c/e4c4a5074532eaaa14951994a3aad0d479aa7431
- https://git.kernel.org/stable/c/f8a5203596797f394ff3f9aa4005597a92249802
- https://access.redhat.com/security/cve/CVE-2026-52972
- https://bugzilla.redhat.com/show_bug.cgi?id=2492364
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52972.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: tls: fix strparser anchor skb leak on offload RX setup failure When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0c9f399b37ce22a5ed94cc51f03ed07ac7f38e32
- https://git.kernel.org/stable/c/3c405dfa9619e506e75b8e41f8b29a5b99731877
- https://git.kernel.org/stable/c/58689498ca3384851145a754dbb1d8ed1cf9fb54
- https://git.kernel.org/stable/c/688f12aa44511dd57e448eb670075c6302ad1dc1
- https://git.kernel.org/stable/c/9c54e76f8d6eb11735918777ef0e0509e089557d
- https://git.kernel.org/stable/c/bd07fe6c38b9e44ff3fc02692a53f095c5cc9afc
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Fix both by: - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump to kill_exec_queue so that xe_exec_queue_kill() properly removes the queue from the VM's compute list. - Adding a del_hw_engine_group label before kill_exec_queue for the xa_alloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup. (cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8)
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1be55646d8a2035343b012dcb12210db7bb8b056
- https://git.kernel.org/stable/c/753b149d5a433eb19e0c1b0eb4526a6e26120d1f
- https://git.kernel.org/stable/c/f3cc22d4df3ed58439ea7e21daa54c3608e03b78
- https://git.kernel.org/stable/c/f93b00161213a0fe9f7ff1d8498ee5ca9e0a5c43
- https://access.redhat.com/errata/RHSA-2026:42919
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/errata/RHSA-2026:52667
- https://access.redhat.com/errata/RHSA-2026:52764
- https://access.redhat.com/security/cve/CVE-2026-52976
- https://bugzilla.redhat.com/show_bug.cgi?id=2492284
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52976.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0
- https://git.kernel.org/stable/c/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf
- https://git.kernel.org/stable/c/4e0ed44e51727d56244a822ab941efe507c47966
- https://git.kernel.org/stable/c/69a7cfc66405aeaa2483147653d031b3592ffc9c
- https://git.kernel.org/stable/c/bc7304f3ae20972d11db6e0b1b541c63feda5f05
- https://git.kernel.org/stable/c/e3f95b1ba242e37093305812df7fdbe7288a43ac
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Clear rel_deadline when initializing forked entities A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference. A captured trace shows the effect clearly. Before yield, the entity's vruntime was around: 9834017729983308 After yield_task_fair() executed: se->vruntime = se->deadline the vruntime jumped to: 19668035460670230 and the deadline was later advanced further to: 19668035463470230 This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime. rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.5
In the Linux kernel, the following vulnerability has been resolved: neigh: let neigh_xmit take skb ownership neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0084712e0bee204b284510cdb63182fd5a30c2b7
- https://git.kernel.org/stable/c/4438113be604ee67a7bf4f81da6e1cca41332ce4
- https://git.kernel.org/stable/c/445e45a2c3a078316a62d2d331a570cf34ef5079
- https://git.kernel.org/stable/c/63063ba60d2dc334e34f1e3f9271d7f3f6f30307
- https://git.kernel.org/stable/c/8a89054a1ec0767aec25ed2bbac933da6ba3cf5a
- https://git.kernel.org/stable/c/9247d59ca15bf60a57dca08103f055d8a4340877
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/23f0e34c64acba15cad4d23e50f41f533da195fa
- https://git.kernel.org/stable/c/24831b0b2ada9fef18d1f486b7b7c444ee5ba637
- https://git.kernel.org/stable/c/30cf9829d09ca958279c937af8e35495cd2f1e09
- https://git.kernel.org/stable/c/423b5b86e14e190f6e3161eb5f2ea5f908295ba7
- https://git.kernel.org/stable/c/4dd7eb94f79486b77ca6b4c8676aedbc465dc802
- https://git.kernel.org/stable/c/5af290c86fa81ddbc86a08d54229af5daa40c6a4
- https://git.kernel.org/stable/c/5db090ca07b28a63fb1499690cf19a3f3adafacb
- https://git.kernel.org/stable/c/6999d70e0eda39af029fa1891c48f0a8832b09d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: fix queue limit check to include reordered packets The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0f875d52db4c921da610e481b72f03cc82fdcb72
- https://git.kernel.org/stable/c/39a66e83ea41fe845631eeb8d326953de27d13f9
- https://git.kernel.org/stable/c/4185701fcce6b426b6c3630b25330dddd9c47b0d
- https://git.kernel.org/stable/c/54b5dbacd00dedffd5e2eed76de1c3839996b5e6
- https://git.kernel.org/stable/c/74fcd8e127200a50ee22ba2b45c164722bdb9177
- https://git.kernel.org/stable/c/8450462eaf91d5d2a9e863507b16d18e814baef3
- https://git.kernel.org/stable/c/936a7dd87251f6f3e88983350833edf60fe6a80b
- https://git.kernel.org/stable/c/ef9a41b3870fb90577da5b2de5bd140022d4021e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netdevsim: zero initialize struct iphdr in dummy sk_buff Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/175556c049eaec14efde8c6475e763b7579b9de7
- https://git.kernel.org/stable/c/1b7b6ae0e93b8d512e208b1378d74af052e4f4e7
- https://git.kernel.org/stable/c/35eaa6d8d6c2ee65e96f507add856e0eacf24591
- https://git.kernel.org/stable/c/6e2cfd0904976e701d7a76b86b694e72af230ab0
- https://git.kernel.org/stable/c/750d0091bebf44975421268d37484ef87060d263
- https://git.kernel.org/stable/c/818f7673ed7f4a29d4b9cee8184c47d6e57162b4
- https://git.kernel.org/stable/c/978ca6ff789f1f19c03288ac20cc1f4774e88490
- https://git.kernel.org/stable/c/bc6002865e8c4fcf9e94975f7cf023448d8764e2
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: don't use simple_strtoul
Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),
and ct_sip_parse_request() with a new sip_parse_port() helper that
validates each digit against the buffer limit, eliminating the use of
simple_strtoul() which assumes NUL-terminated strings.
The previous code dereferenced pointers without bounds checks after
sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated
skb data. A port that reaches the buffer limit without a trailing
character is also rejected as malformed.
Also get rid of all simple_strtoul() usage in conntrack, prefer a
stricter version instead. There are intentional changes:
- Bail out if number is > UINT_MAX and indicate a failure, same for
too long sequences.
While we do accept 05535 as port 5535, we will not accept e.g.
'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261,
we should restrict this to not waste cycles when presented with
malformed packets with 64k '0' characters.
- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch
'expire=' and 'rports='; both are expected to use base-10.
- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k
range.
- epaddr_len now returns 0 if the port is invalid, as it already does
for invalid ip addresses. This is intentional. nf_conntrack_sip
performs lots of guesswork to find the right parts of the message
to parse. Being stricter could break existing setups.
Connection tracking helpers are designed to allow traffic to
pass, not to block it.
Based on an earlier patch from Jenny Guanni Qu .
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/523762e3b6933fff81f01dfa3c60c0774044cdab
- https://git.kernel.org/stable/c/7df9863bf538a626e8a684e59cb2c43eac0ef3c8
- https://git.kernel.org/stable/c/8cd0358379570003659186706e077929d6930c40
- https://git.kernel.org/stable/c/8cf6809cddcbe301aedfc6b51bcd4944d45795f6
- https://git.kernel.org/stable/c/9c6afcb1c3cbb2c0da65b8515ac14d7273872f84
- https://git.kernel.org/stable/c/9f69c323ae0ab517e595c2cc74e0ae0d9d085611
- https://git.kernel.org/stable/c/b3264c977e79d8a25778d4fd11520f00fea1329c
- https://git.kernel.org/stable/c/ea2ecd29b8f4433e52607192ca91084f95787ca0
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/046fa5c72d15cd8e2d592e275697ea399d8f76b0
- https://git.kernel.org/stable/c/3df42a854686fa06484e37ac1a3931c8e3e3453c
- https://git.kernel.org/stable/c/c2a11441538bdbbc5aa003f190995eba93a89b88
- https://git.kernel.org/stable/c/d7c8f95f599b3b38a717d2e771c3f8c174f657c3
- https://git.kernel.org/stable/c/ea8e356acb165cb1fd75537a52e1f66e5e76c538
- https://git.kernel.org/stable/c/f9204a2b78dd18374d3bcf9bf93d9021ce22de1b
- https://access.redhat.com/security/cve/CVE-2026-52989
- https://bugzilla.redhat.com/show_bug.cgi?id=2492443
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52989.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fsnotify: fix inode reference leak in fsnotify_recalc_mask() fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared. This manifests as a hung task with the following call trace: INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exit The race window that triggers the iref leak: Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return /* ---- gap: no lock held ---- */ fsnotify_detach_mark(mark_A): spin_lock(mark_A->lock) clear ATTACHED flag on mark_A spin_unlock(mark_A->lock) fsnotify_put_mark(mark_A) fsnotify_recalc_mask(): spin_lock(conn->lock) __fsnotify_recalc_mask(): /* mark_A skipped: ATTACHED cleared */ /* only mark_B(evictable) remains */ want_iref = false has_iref = true /* not yet cleared */ -> HAS_IREF transitions true -> false -> returns inode pointer spin_unlock(conn->lock) /* BUG: return value discarded! * iput() and fsnotify_put_sb_watched_objects() * are never called */ Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/adfs: validate nzones in adfs_validate_bblk() Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1586bd2d2fb436a26df20a70e78b000d34a7d159
- https://git.kernel.org/stable/c/1f0ed0f57f0fc87e46fe19a05435c214dc464be2
- https://git.kernel.org/stable/c/33aafd2418a59c96c0389d47ea09026661fa9ec6
- https://git.kernel.org/stable/c/60d82592ac8b5637fbed871381eb0a16df0a492e
- https://git.kernel.org/stable/c/6ff8cca5cdb4f2e0ea6d28ecd78479dd3f221ebc
- https://git.kernel.org/stable/c/a11372a8b1ceaa5e950a84b3b5fbf8228f25e277
- https://git.kernel.org/stable/c/a3fd5dc1c7b0aae947a67dc2e2c037d57557a4de
- https://git.kernel.org/stable/c/dd9d3e16c2d5fa166e13dce07413be51f42c8f5d
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0274f24485fc38032d4093e463dc3ff5c7a667c9
- https://git.kernel.org/stable/c/1d5e589055880fae229e229e1929e087dbe08cf3
- https://git.kernel.org/stable/c/29940fff14110ca48c5ccc168d121665b51bb778
- https://git.kernel.org/stable/c/4d104882bc815d4ec666ace9155f5f52715879a6
- https://git.kernel.org/stable/c/4ee4deadaae7cb2e3d53af0fc889cf92a73413c0
- https://git.kernel.org/stable/c/a438975a6dcdbd70865978c021650d1485586f0b
- https://git.kernel.org/stable/c/d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a
- https://git.kernel.org/stable/c/d3556656c6daebf8def751c7e71d11dd0a180d24
- https://access.redhat.com/errata/RHSA-2026:45115
- https://access.redhat.com/errata/RHSA-2026:45116
- https://access.redhat.com/errata/RHSA-2026:47017
- https://access.redhat.com/errata/RHSA-2026:49212
- https://access.redhat.com/security/cve/CVE-2026-52993
- https://bugzilla.redhat.com/show_bug.cgi?id=2492437
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52993.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0797b2e6901827694aa9c34c4c72118c8c97fba1
- https://git.kernel.org/stable/c/5e67cc262afb384e835c3327e9d954eeaedc6a87
- https://git.kernel.org/stable/c/81651e9d7dea1c048d2952f57632a042931d7b43
- https://git.kernel.org/stable/c/912ba2e5704fdb8bc5decda96dfc1a57838f0099
- https://git.kernel.org/stable/c/91ce1bb6e4194dc2321748f68145359dcf86e350
- https://git.kernel.org/stable/c/b6ba93a7b71ed443c9843eb12d27ed86f1e52694
- https://git.kernel.org/stable/c/c7cb9eed8215a790f052f49cdccf577720d2bb62
- https://git.kernel.org/stable/c/c88eb7e8d8397a8c1db59c425332c5a30b2a1682
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid(). Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked. Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks. Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/06f709d0e531f3e54d88665dd426be3998a774e6
- https://git.kernel.org/stable/c/407b6e699ba8b45b72cc265eed8a1bc8a7191609
- https://git.kernel.org/stable/c/804054d19886ac6628883d82410f6ee42a818664
- https://git.kernel.org/stable/c/8c4a0ef19c8264c150833131af34541495832cd0
- https://git.kernel.org/stable/c/f31beef633fbf2b5af7805fa187a10bcff1d4b49
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/5d05de2f0928d81309a815ecc76d1a3ad72cbc16
- https://git.kernel.org/stable/c/711987ba281fd806322a7cd244e98e2a81903114
- https://git.kernel.org/stable/c/79b90a96688e521771fa6ed3dc7864b76b8df293
- https://git.kernel.org/stable/c/83fc5dd63455a779ea2dd0f7ffee3c920919d80b
- https://git.kernel.org/stable/c/95be653a76793856ff8b2d8bd82c2943c23f5ca8
- https://git.kernel.org/stable/c/c996a90f3071cf43683e5423da31aadbe002b8b4
- https://git.kernel.org/stable/c/edc806f9122961f0d3819f7c69c14cccde31f277
- https://git.kernel.org/stable/c/f4de0777e4554a7de19c920accde6319dd530782
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix out-of-bounds read on option matching In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.
CVSS 3.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0145548346c4a30981a870a8ca00eac46ba27e85
- https://git.kernel.org/stable/c/1c136f2c44a5913646bac85303612fd0825197a0
- https://git.kernel.org/stable/c/1e19a07291bb8682c14c39a64725a3ae54ab8ccc
- https://git.kernel.org/stable/c/21883587593d7c8bb519a79460a0b5bc5ffbdabd
- https://git.kernel.org/stable/c/32e50f92c7cf3f4eba29622179a5fcdc2aebab41
- https://git.kernel.org/stable/c/70a3f31d25cf2ec9d4ddfa408120171ead955623
- https://git.kernel.org/stable/c/edb78a142d2e5948e63647c0646aa7e7886935f0
- https://git.kernel.org/stable/c/f5ca450087c3baf3651055e7a6de92600f827af3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: restrict several matches to inet family This is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") to allow ipv4 and ipv6 only. - xt_mac - xt_owner - xt_physdev These extensions are not used by ebtables in userspace. Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4 specific.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/14203f9edf944b3fb63faadd62f38452421ecdfc
- https://git.kernel.org/stable/c/689a91ff18d6448d94c1ab7c076fecdb2b668bef
- https://git.kernel.org/stable/c/76160e04440c9698b989dbd9492a7ec4f520c9ee
- https://git.kernel.org/stable/c/7eaf9c740f33230cb224dc265f3c69f8531ff57b
- https://git.kernel.org/stable/c/9a109751b297b0f2135495749ef5a18ba31ec7d4
- https://git.kernel.org/stable/c/b6fe26f86a1649f84e057f3f15605b08eda15497
- https://git.kernel.org/stable/c/cbeb259f31382de70a70a59ffd0e66f5e80d9818
- https://git.kernel.org/stable/c/fa88161ef56e29bdaa05cc89dbc4ee221e94bfe9
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: remove sprintf usage Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1c9fb8aeed06790d42cdcd00f6c3ce0b9e926c1e
- https://git.kernel.org/stable/c/2f793ba78470a99f40389b7dc60a81d9f5ad3956
- https://git.kernel.org/stable/c/6bbf829b4c1b44c941c47dd0d710f1393258f3d5
- https://git.kernel.org/stable/c/6e7066bdb481a87fe88c4fa563e348c03b2d373d
- https://git.kernel.org/stable/c/8e3be0d12615a173fe260cd42753ca7a001acbf2
- https://git.kernel.org/stable/c/a8e0a32a23d3f34862af3b4da792ecb3a891a9a3
- https://git.kernel.org/stable/c/ab64e61c9323fa6de21bd20da1ddb29a0fb65d34
- https://git.kernel.org/stable/c/c08ff52e44945e6ef4ce0790f49ea761b060c45b
- https://access.redhat.com/security/cve/CVE-2026-53002
- https://bugzilla.redhat.com/show_bug.cgi?id=2492329
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53002.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: pppoe: drop PFC frames RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames. If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures. To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0cab5d077dd1efd2bd1a47271acc35894f945b4f
- https://git.kernel.org/stable/c/2b5c3c040d020e3ab3b9a8887031202d96843b1e
- https://git.kernel.org/stable/c/49e41b60ccd1bdbe9e218420f716dd5f9a2f9c71
- https://git.kernel.org/stable/c/8a5e840babc5c0fbd10c73728a13192347771ec6
- https://git.kernel.org/stable/c/ba758fdf1399f310b30098b6faa3fd043de47dd2
- https://git.kernel.org/stable/c/cb3beef35ab5e0c1afca9fd7648c6ae499786377
- https://git.kernel.org/stable/c/cc1ff87bce1ccd38410ab10960f576dcd17db679
- https://git.kernel.org/stable/c/fcca1df05322bb04e344dd1178b54b76a08eb7c3
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0cf004ffb61cd32d140531c3a84afe975f9fc7ea
- https://git.kernel.org/stable/c/2b5a2c957c7769d40110f725cf23987fcef50d75
- https://git.kernel.org/stable/c/6849b995cda88a677bf08a05765d1db7905974fc
- https://git.kernel.org/stable/c/6bcf8fe4ef7967b22b814cbae9a57bbd3c853410
- https://git.kernel.org/stable/c/70a089cc9590aa347a61e84434116ab74619e3c3
- https://git.kernel.org/stable/c/a132e199de69e2a45628aa8534df1bf5d44e1b6e
- https://git.kernel.org/stable/c/d45c7e99caf915b0f6c716bd8ffe9d45b9685761
- https://git.kernel.org/stable/c/d67fbc6dea5dbf7f46c618ebf65910a276078e20
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0069813e6ca9309eca78022bcb3aeb1e9ef90a12
- https://git.kernel.org/stable/c/085e31a811ef234ef8c3e219c4636dfebfe7e10f
- https://git.kernel.org/stable/c/1e1f0f89ee4692a64be3f3707ff8ac1ae57b03e7
- https://git.kernel.org/stable/c/38bdbc897c0d83a3e2b925a51b69420f1feba29a
- https://git.kernel.org/stable/c/7bff2c8fe5c35ae58bf73104f53db3676e6e5d94
- https://git.kernel.org/stable/c/7c66b368c6ff453f99cb39d84af93e908e51eef2
- https://git.kernel.org/stable/c/aff0f28f5be803de2452ce702631c021fcd9ce8a
- https://git.kernel.org/stable/c/f996edd7615e686ada141b7f3395025729ff8ccb
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/errata/RHSA-2026:47010
- https://access.redhat.com/errata/RHSA-2026:47011
- https://access.redhat.com/errata/RHSA-2026:47017
- https://access.redhat.com/security/cve/CVE-2026-53006
- https://bugzilla.redhat.com/show_bug.cgi?id=2492363
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53006.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: fix use-after-free in advance_sched() on schedule switch In advance_sched(), when should_change_schedules() returns true, switch_schedules() is called to promote the admin schedule to oper. switch_schedules() queues the old oper schedule for RCU freeing via call_rcu(), but 'next' still points into an entry of the old oper schedule. The subsequent 'next->end_time = end_time' and rcu_assign_pointer(q->current_entry, next) are use-after-free. Fix this by selecting 'next' from the new oper schedule immediately after switch_schedules(), and using its pre-calculated end_time. setup_first_end_time() sets the first entry's end_time to base_time + interval when the schedule is installed, so the value is already correct. The deleted 'end_time = sched_base_time(admin)' assignment was also harmful independently: it would overwrite the new first entry's pre-calculated end_time with just base_time.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0e62171df8ed4804d00db088f17eed06468233fa
- https://git.kernel.org/stable/c/105425b1969c5affe532713cfac1c0b320d7ac2b
- https://git.kernel.org/stable/c/1bd286fa3e21200133478ed523cc6a2788baf38a
- https://git.kernel.org/stable/c/3471874578160a28c171a607fa069f24062634b8
- https://git.kernel.org/stable/c/7256996e1ef553716817f3bfd077c2f3b48b582f
- https://git.kernel.org/stable/c/a8fc396519ef4f081bc545e88f61241728bb78d7
- https://git.kernel.org/stable/c/b73235da5dde77ed1264f9767b62c28c9d71fd78
- https://git.kernel.org/stable/c/eee072fe16c646190d33ae69c9983d8de1562bf8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nexthop: fix IPv6 route referencing IPv4 nexthop syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/29c95185ba32b621fbc3800fb86e7dc3edf5c2be
- https://git.kernel.org/stable/c/613c8f4a501421dd258b07ea614205d4e16ec845
- https://git.kernel.org/stable/c/6275796f22bb382f3e9aa58ed0b4ef7bdad78cb8
- https://git.kernel.org/stable/c/9c2d6770a5f4545a307eb66979bef7656a34d621
- https://git.kernel.org/stable/c/aaac3bed034239e1d75732211d9b05f30b0b4f35
- https://git.kernel.org/stable/c/ad85961004fd4bd2f31209ac4b07612c6cefb9e7
- https://git.kernel.org/stable/c/b3b7e850e1541f0520c4a12ec884255c30427ff6
- https://git.kernel.org/stable/c/ceffe81a0be92afc0cd1340bc8ca46559cce9bb4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1. This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb runs out of space, triggering a WARN_ON in rtnetlink and preventing the interface from being dumped. The bug can be reproduced with: ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bc_cutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZE The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff"), which added the nla_put_s32() call in macvlan_fill_info() but missed adding the corresponding nla_total_size(4) in macvlan_get_size(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still did not fix the size calculation.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1c004f14ccdc11585625c168bb9a7c5e1b8afb0c
- https://git.kernel.org/stable/c/4979252758387b338ca968ba7e0515b0ae2257e3
- https://git.kernel.org/stable/c/77ecfa4e27f282d224215895ddfbeb916fc75e24
- https://git.kernel.org/stable/c/b6b7154e9f5d75b608ceb2d05b376de8c638c40e
- https://git.kernel.org/stable/c/fa92a77b0ed4d5f11a71665a232ac5a54a4b055d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: erofs: unify lcn as u64 for 32-bit platforms As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB. In order to consolidate the logic, just use `u64` consistently around the codebase. [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/227c1e1d9e2aa4cfc65ba446d5690da1f546cda4
- https://git.kernel.org/stable/c/798d409a8949f3f495f238549b86de2886b129bd
- https://git.kernel.org/stable/c/939061b2d0f7f15114e34b4ce878ef50ff4089c3
- https://git.kernel.org/stable/c/a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4
- https://git.kernel.org/stable/c/bb01d8f1f385bc9034ca114d3508c7fdea24fc9a
- https://git.kernel.org/stable/c/df9784bb5b637ac80f4a2768a58ca9a50bef28a9
- https://git.kernel.org/stable/c/dfb2cf434829819268fe50f41542aad318ad62b2
- https://git.kernel.org/stable/c/eecee15e263ccb8cd77170a56ab6c969cb54dd6a
- https://access.redhat.com/errata/RHSA-2026:38491
- https://access.redhat.com/errata/RHSA-2026:39494
- https://access.redhat.com/security/cve/CVE-2026-53016
- https://bugzilla.redhat.com/show_bug.cgi?id=2492269
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53016.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix integer overflow in UNMAP bounds check sbc_execute_unmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow. Add an overflow check matching the pattern already used for WRITE_SAME in the same file.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/02115986d027ade793e7f6be87e91d6a796d0aa3
- https://git.kernel.org/stable/c/2bf2d65f76697820dbc4227d13866293576dd90a
- https://git.kernel.org/stable/c/2e1ed9a7b6ea5bfefb5d80a02b1c71c7dee1f0dd
- https://git.kernel.org/stable/c/3facdecc3fcf115cc4f9b3d8f118d6705e2456a8
- https://git.kernel.org/stable/c/51075df70c46e60a9773f2dcd28299e40dac36fb
- https://git.kernel.org/stable/c/5efc3ef4758f8d98c257419fa21daca3227de61a
- https://git.kernel.org/stable/c/c08ab702c4699c6efb9d60bdb15b73e7a627ee7e
- https://git.kernel.org/stable/c/d7aef29573c7c5cdb2dfad939253287a6329c2a4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: bound enumeration string aggregation populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. [ij: add include]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3c34471c26abc52a37f5ad90949e2e4b8027eb14
- https://git.kernel.org/stable/c/5a04f9a36930792f6d64e28d43609e158d09b665
- https://git.kernel.org/stable/c/75c738d4f27fa18a2a033de153bd40302bde6a66
- https://git.kernel.org/stable/c/7b3dc1f764bf24eb99474a5de8173b0b43a8b071
- https://git.kernel.org/stable/c/90b118d264845f7aaf539ac49f7c75f1f29590e2
- https://git.kernel.org/stable/c/ba0843c1955864401295f7ba3b420afe19f2266d
- https://git.kernel.org/stable/c/c5683ca4949a514fbe656c6d0d08c4c126e21db9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: terminate the cached volume label after UTF-8 conversion ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0b11fcbe80a59acdf58337d80ebb5f72201d73d6
- https://git.kernel.org/stable/c/32b0686369e0afbb3549a0d93e2d8517da84cd30
- https://git.kernel.org/stable/c/54d564b762389679e2f8fb9eeb20af7e82371e1c
- https://git.kernel.org/stable/c/5cd0707b81cb4589f00aec5c4c1288bd0980d2a4
- https://git.kernel.org/stable/c/6136bbb054f7ab9f51ae99915541633b18bcef90
- https://git.kernel.org/stable/c/a6cd43fe9b083fa23fe1595666d5738856cb261a
- https://git.kernel.org/stable/c/bc7a0c34c4ca259cfddf3bc18fc5b3c6411d26ed
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Validate node_id in arena_alloc_pages() arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL deref in map_kptr_match_type for scalar regs Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a36c1f72888bca0237295a4da19cd91821a90be
- https://git.kernel.org/stable/c/4d0a375887ab4d49e4da1ff10f9606cab8f7c3ad
- https://git.kernel.org/stable/c/520454e839710c327808c2fcc98e28cee77355fc
- https://git.kernel.org/stable/c/6982653ce5f119982aa58f1af58e7bfbebf39252
- https://git.kernel.org/stable/c/da1d615ce49a47986a8864e2371a26e97861085c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Take state lock for af_unix iter When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1a59cc6b65fd3ad9915aae5970d859109d4ce9fb
- https://git.kernel.org/stable/c/64c2f93fc3254d3bf5de4445fb732ee5c451edb6
- https://git.kernel.org/stable/c/921920c34cb591947dd30c692500795a69f1e3fa
- https://git.kernel.org/stable/c/98f744d204e5d6fca589cd2c44c3190a0c71697f
- https://git.kernel.org/stable/c/c6f4015eac2e3cbc3cb7a17539e10bbb5c2049c3
- https://git.kernel.org/stable/c/d0d124dbcef9318e326956137b31671407094bd4
- https://access.redhat.com/security/cve/CVE-2026-53033
- https://bugzilla.redhat.com/show_bug.cgi?id=2492281
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53033.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix af_unix null-ptr-deref in proto update unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() ---truncated---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0
- https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0
- https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317
- https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4
- https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10
- https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix af_unix iter deadlock bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3cef33b9813b78f227942572fb317afcd5c9ac94
- https://git.kernel.org/stable/c/4d328dd695383224aa750ddee6b4ad40c0f8d205
- https://git.kernel.org/stable/c/527057ebe8076dfbcaef51195ff1b7508646be2c
- https://git.kernel.org/stable/c/66d9fab4565eafe1afe7ba0581f79b76073b60fa
- https://git.kernel.org/stable/c/87828b380956d4986f59f2c086e0b09b3e6cdaae
- https://git.kernel.org/stable/c/bd3592129f24243713673a07225cf1f15a9bb835
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix off-by-one in check_imm signed range check check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1a113b5497297871699cd498b1b83542e0db7f15
- https://git.kernel.org/stable/c/1dd8be4ec722ce54e4cace59f3a4ba658111b3ec
- https://git.kernel.org/stable/c/6927f0d6794aa73318bbfa929f1ff6065b0620df
- https://git.kernel.org/stable/c/7fd3b41260c6120e7b60164afea5d961af6224f9
- https://git.kernel.org/stable/c/a5dfeb3b61065039488342d43ae06d4729d955d4
- https://git.kernel.org/stable/c/fb74defa1cca1a73177c0c761e641332e4f979a3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4e900465296ce9fb12ed47dc77389b8dde95bfe0
- https://git.kernel.org/stable/c/56d318ef8766f0deb08517fd8f3007256ea7997d
- https://git.kernel.org/stable/c/8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72
- https://git.kernel.org/stable/c/90550af0aad5e75110073c501e4fb42fca20ff80
- https://git.kernel.org/stable/c/ad4505d2ab3aaac6498f17649608e70e80034bf2
- https://git.kernel.org/stable/c/b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e
- https://git.kernel.org/stable/c/c7abd0e6c87441e99c759d40eb6fe589634e3041
- https://git.kernel.org/stable/c/eeceb6f4dd42065fdda3a526a93d08b8fb90fb69
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ima_fs: Correctly create securityfs files for unsupported hash algos
ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
HASH_ALGO__LAST if the TPM algorithm is not supported. However there
are places relying on the algorithm to be valid because it is accessed
by hash_algo_name[].
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
==================================================================
BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
Call Trace:
dump_stack_lvl+0x61/0x90
print_report+0xc4/0x580
? kasan_addr_to_slab+0x26/0x80
? create_securityfs_measurement_lists+0x396/0x440
kasan_report+0xc2/0x100
? create_securityfs_measurement_lists+0x396/0x440
create_securityfs_measurement_lists+0x396/0x440
ima_fs_init+0xa3/0x300
ima_init+0x7d/0xd0
init_ima+0x28/0x100
do_one_initcall+0xa6/0x3e0
kernel_init_freeable+0x455/0x740
kernel_init+0x24/0x1d0
ret_from_fork+0x38/0x80
ret_from_fork_asm+0x11/0x20
The buggy address belongs to the variable:
hash_algo_name+0xb8/0x420
Memory state around the buggy address:
ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
^
ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
tpm tpm0: TPM with unsupported bank algorithm 0x0027
That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
Library Part 2: Structures", page 51 [1].
See also the related U-Boot algorithms update [2].
Thus solve the problem by creating a file name with "_tpm_alg_"
postfix if the crypto algorithm isn't initialized.
This is how it looks on the test machine (patch ported to v6.12 release):
# ls -1 /sys/kernel/security/ima/
ascii_runtime_measurements
ascii_runtime_measurements_tpm_alg_27
ascii_runtime_measurements_sha1
ascii_runtime_measurements_sha256
binary_runtime_measurements
binary_runtime_measurements_tpm_alg_27
binary_runtime_measurements_sha1
binary_runtime_measurements_sha256
policy
runtime_measurements_count
violations
[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
[2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate group add input before caching [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/22544ddedf381ed5191cfc783aea8d6c936bc201
- https://git.kernel.org/stable/c/6c5e70409c1961fe1278968f038eaaed6cc1145a
- https://git.kernel.org/stable/c/70b672833f4025341c11b22c7f83778a5cd611bc
- https://git.kernel.org/stable/c/76bd722db0a92b84ccd99e03796a0b6f1ae71c31
- https://git.kernel.org/stable/c/aed87e866d1a321edb9703563c2faa8fec89835d
- https://git.kernel.org/stable/c/b9ae3942deec4c9e3fa2070521f90910f7490011
- https://git.kernel.org/stable/c/e7c2cb552e6eb85c0f5aefdd7f0f7c3c8591a6a3
- https://git.kernel.org/stable/c/f7e139d7563f6947ad509fb468903941d0bb7ddd
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate bg_bits during freefrag scan [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/05d0cbea41167b6b061c6ba5b70ee5a9a7a24c9e
- https://git.kernel.org/stable/c/0998674eec138c55e9e349b9cbd9dbc5129a9cc8
- https://git.kernel.org/stable/c/3e167e230d19cd273108bab2e4c61800fc335ae8
- https://git.kernel.org/stable/c/4c2d62ddde8928db12f4608950b67a20e67deab2
- https://git.kernel.org/stable/c/8f687eeed3da3012152b0f9473f578869de0cd7b
- https://git.kernel.org/stable/c/bb2906a1065ec28de021bac2ed03f2624edd7d07
- https://git.kernel.org/stable/c/bb3c54d1e71578521111f1a1ee7d5f4761a242b8
- https://git.kernel.org/stable/c/e0dcf12665d6dde37facf790803cdad44d5c328c
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix listxattr handling when the buffer is full [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2323084c17370304f49c84b354fe7b3edbb264fe
- https://git.kernel.org/stable/c/2685df8577a38d83b367c8cf52eda9dc286959ff
- https://git.kernel.org/stable/c/46e66fefb83811958127bc9ad736983ec629d82b
- https://git.kernel.org/stable/c/50033ec1350fe68abdc63b950ced7ae57364b77a
- https://git.kernel.org/stable/c/6f702b00b8124c5d3525f19172934544826a114d
- https://git.kernel.org/stable/c/a35a1c2b170b5b578b1b3fecb95694796552af9a
- https://git.kernel.org/stable/c/d12f558e6200b3f47dbef9331ed6d115d2410e59
- https://git.kernel.org/stable/c/d919b905939eda93393e3572900ff70dbad2b47f
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: validate qr_numregions in dlm_match_regions() Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops.
CVSS 3.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1f8b91275912cd428289c1fb424bebd7ff5302bd
- https://git.kernel.org/stable/c/3c2d0de23ae4be22b6c18e8f0915be74d3b5fb21
- https://git.kernel.org/stable/c/3f474c33ebc2e2ca3fcb587d7de4375348f13373
- https://git.kernel.org/stable/c/6c6e8fc3c007319981647b410c29bb5775048551
- https://git.kernel.org/stable/c/7ab3fbb01bc6d79091bc375e5235d360cd9b78be
- https://git.kernel.org/stable/c/d3d5efade0c79dac1cac98c0cb1115432f804439
- https://git.kernel.org/stable/c/f37de46149db49abd2b24f4f0c5a88cf4dfb5f47
- https://git.kernel.org/stable/c/f69551139caf6d24242a0ad049ee46b264e3aee0
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: memory: tegra124-emc: Fix dll_change check The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/05f138fc7e27ee8e7a83ccf966c3fa26cda44dda
- https://git.kernel.org/stable/c/1793249c067a4b28e1aba0ad0e4d73aa9f9e165a
- https://git.kernel.org/stable/c/1ebbbef47d11cc90219c081492ccf995aaa3e9b3
- https://git.kernel.org/stable/c/2369b1831161356e1bcb51385d3e532dc4fe2771
- https://git.kernel.org/stable/c/7e19e72f306484996c52ff96cc92f69b78ed5435
- https://git.kernel.org/stable/c/9597ab9a8296ab337e6820f8a717ff621078b632
- https://git.kernel.org/stable/c/a85967331144fde9300be38bb44d2558eb6b742e
- https://git.kernel.org/stable/c/db0ae80865b515cc0b705c85877ec00f7eebe9fe
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine ksmbd_crypt_message() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash: pc : qce_skcipher_done+0x24/0x174 lr : vchan_complete+0x230/0x27c ... el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] Use the standard crypto_wait_req() pattern with crypto_req_done() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification).
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/3e298897f41c61450c2e7a4f457e8b2485eb35b3
- https://git.kernel.org/stable/c/57b47231055b431ed0a1a55f33cac32981564405
- https://git.kernel.org/stable/c/7164b3953cefd540e7ebca828c793bc6869cfbc4
- https://git.kernel.org/stable/c/8ef183216feaa24b66b940510d8b68f680eb56e9
- https://git.kernel.org/stable/c/8fcefe840fa8c14ce667768e5b043286ac3bbcbe
- https://git.kernel.org/stable/c/b46aa129fa2807bfe1545fe74d9295d53c51520b
- https://git.kernel.org/stable/c/cc2da381875d4a67026e4c8feb3dba51a2a2d1bc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect sizeof in phys array reallocation The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/22022cd8851703a58f67615a17bc7e9e8682785b
- https://git.kernel.org/stable/c/48a428215782321b56956974f23593e40ce84b7a
- https://git.kernel.org/stable/c/5e185330d902b12fe8e6eb4b8514b5d736d8d66d
- https://git.kernel.org/stable/c/608e1f7bc9d171ab26c1fba288c97fc76363c27d
- https://git.kernel.org/stable/c/67adde6bfdfd563a54b045d59aeb9a2d90c80697
- https://git.kernel.org/stable/c/8be69e9245f805566bac68ffc8574b64735fd996
- https://git.kernel.org/stable/c/ab3f7098a3a27175b91cfc947950f5c26855801b
- https://git.kernel.org/stable/c/e0e6b14995fd6fa2c0df8c712d76ab32f0694c31
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/233a0945a4b1dbe3f38c30afb7d05b76c67f1193
- https://git.kernel.org/stable/c/2fc4c868c9060f424fd4a7cacb0aec5082aba4de
- https://git.kernel.org/stable/c/74b4dbb946060a3233604d91859a9abd3708141d
- https://git.kernel.org/stable/c/abd73229f0e886a91a16ea781ab656bd9b4d1ee8
- https://git.kernel.org/stable/c/cec55674354794eddb80b914f73a6bf9b7fc304a
- https://git.kernel.org/stable/c/d8ffae016c4a78693fe1283335d0b6833a9c1366
- https://git.kernel.org/stable/c/e15f16761594e80b15776980b27c35477655a135
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: gfs2: add some missing log locking Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush().
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/3b28eb75afe520972bacc833850c2b30aa0824cd
- https://git.kernel.org/stable/c/49d9be0722da3a4a893ba905720cba1921834ec3
- https://git.kernel.org/stable/c/98e8bf249c790d56de1abc4a5f8bd68035a00921
- https://git.kernel.org/stable/c/bf5fcd9c37c2546beaf7b401d31aefd89017dc3d
- https://git.kernel.org/stable/c/ca95342cb1b39062a03c115830286f0a426053d5
- https://git.kernel.org/stable/c/f2f225cf505ac016132ded21690f3ba0a080a4e8
- https://git.kernel.org/stable/c/fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: quota: Fix race of dquot_scan_active() with quota deactivation dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/2bdc80f4619411e5bd4a3ef23f51e14021ed457c
- https://git.kernel.org/stable/c/61e25f664dc2a08299e07d84c85776abc2350f75
- https://git.kernel.org/stable/c/6678dde265708003c2b42551af4a2e3cb05decd5
- https://git.kernel.org/stable/c/82cbdb4c1ebb5ea7d7bd45c18d3483b5bd32ebc1
- https://git.kernel.org/stable/c/ac8a2e0d287ebf35e5d7e51e260b4e146648ba4a
- https://git.kernel.org/stable/c/e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d
- https://git.kernel.org/stable/c/f9438cb8c8ec3adc84b2b450a3aab0123d074c3b
- https://git.kernel.org/stable/c/fdd424d7c35633ac577fd87d1b043d1b8a6cd350
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: qdsp6: topology: check widget type before accessing data Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1ac96689ce2984f4f6ef8892fcb65da377408421
- https://git.kernel.org/stable/c/296810e91f21a21794886c57f954495d8afd7f32
- https://git.kernel.org/stable/c/6d2491a585202a967ed91f30ec5960024f2536d0
- https://git.kernel.org/stable/c/8e8cd78b6000c9d19db249a5a68287158f288ef3
- https://git.kernel.org/stable/c/a1a24d4b8c9682f9b7a9138f636ff004c721aef1
- https://git.kernel.org/stable/c/d5bfdd28e0cdd45043ae6e0ac168a451d59283dc
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix clone_alias() to use the original device's devid Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: fix mismatch between power and frequency During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Patchwork: https://patchwork.freedesktop.org/patch/710077/
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0ccf4f27b4652570b5de3de02a89a86435559de9
- https://git.kernel.org/stable/c/0f7dd5839cfabaf9c007fb718ec66e907a473c93
- https://git.kernel.org/stable/c/1181a7028d37e0b1e720a36125a03f5db97e3d27
- https://git.kernel.org/stable/c/9830999c9e065c1813ec5435bfe4eab98ee54a87
- https://git.kernel.org/stable/c/bc1dccc518cc5ab5140fba06c27e7188e0ed342b
- https://git.kernel.org/stable/c/c5735c7d0eef7a5240f9c1c66e44ba52a1be58d6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1af3b42e08a957e53bab8e1897393fe0a27d9fbf
- https://git.kernel.org/stable/c/43d6508ddbf9fb974fbc359a033154f78c9d4c8b
- https://git.kernel.org/stable/c/5302015daf26ef6b48e067f2b86c9482ac19e015
- https://git.kernel.org/stable/c/a3611554e599d1a24b45fd8415bacb72ce861e4b
- https://git.kernel.org/stable/c/cf2ac2cac8b319f89b3a3851ca0c5ffb6a549575
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to region_count overflow The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/12bd5b88e91a02785244ff1d20fb157e96e9cdc8
- https://git.kernel.org/stable/c/3ec74da927b4e171a6fc0e77b1188ba4d019af51
- https://git.kernel.org/stable/c/44ab8875ae4a2842bde2d756bed195d375e0debb
- https://git.kernel.org/stable/c/4ec8323b9f0764a14d532b1ae9b87f8a9fecb867
- https://git.kernel.org/stable/c/b455903eed4558982be0811f5b7f44f6bbc4ff57
- https://git.kernel.org/stable/c/c20e36b7631d83e7535877f08af8b0af72c44b1a
- https://git.kernel.org/stable/c/d4ac87567f86a55c3c92e9a5144dcd943a9772a1
- https://git.kernel.org/stable/c/defe483e47173768c227532694dc78cb65db5f09
- https://access.redhat.com/errata/RHSA-2026:45114
- https://access.redhat.com/errata/RHSA-2026:45115
- https://access.redhat.com/errata/RHSA-2026:45116
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/errata/RHSA-2026:47248
- https://access.redhat.com/errata/RHSA-2026:52649
- https://access.redhat.com/errata/RHSA-2026:53989
- https://access.redhat.com/security/cve/CVE-2026-53059
- https://bugzilla.redhat.com/show_bug.cgi?id=2492277
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53059.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
dm cache metadata: fix memory leak on metadata abort retry
When failing to acquire the root_lock in dm_cache_metadata_abort because
the block_manager is read-only, the temporary block_manager created
outside the root_lock is not properly released, causing a memory leak.
Reproduce steps:
This can be reproduced by reloading a new table while the metadata
is read-only. While the second call to dm_cache_metadata_abort is
caused by lack of support for table preload in dm-cache, mentioned
in commit 9b1cc9f251af ("dm cache: share cache-metadata object across
inactive and active DM tables"), it exposes the memory leak in
dm_cache_metadata_abort when the function is called multiple times.
Specifically, dm-cache fails to sync the new cache object's mode during
preresume, creating the reproducer condition.
This issue could also occur through concurrent metadata_operation_failed
calls due to races in cache mode updates, but the table preload scenario
below provides a reliable reproducer.
1. Create a cache device with some faulty trailing metadata blocks
dmsetup create cmeta <
unreferenced object 0xffff8880080c2010 (size 16):
comm "dmsetup", pid 132, jiffies 4294982580
hex dump (first 16 bytes):
00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ...
backtrace (crc 3118f31c):
kmemleak_alloc+0x28/0x40
__kmalloc_cache_noprof+0x3d9/0x510
dm_block_manager_create+0x51/0x140
dm_cache_metadata_abort+0x85/0x320
metadata_operation_failed+0x103/0x1e0
cache_preresume+0xacd/0xe70
dm_table_resume_targets+0xd3/0x320
__dm_resume+0x1b/0xf0
dm_resume+0x127/0x170
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/044ca491d4086dc5bf233e9fcb71db52df32f633
- https://git.kernel.org/stable/c/14f60e957f34f95a626caec76a8fae88cf4c397f
- https://git.kernel.org/stable/c/15c30997dca681f90dbf2d45ee629c1828bf0c0d
- https://git.kernel.org/stable/c/322a3b70368d49e39591fe9fc6c07d262128b05f
- https://git.kernel.org/stable/c/4311ca59a1891d33c4c8b7946f98c34f167fe833
- https://git.kernel.org/stable/c/6b97cc7a42905755c56bbddc33aa8b792205caee
- https://git.kernel.org/stable/c/b0bd35535bdb6f58505f3a30ee5793986943997a
- https://git.kernel.org/stable/c/d1a79620c419a0af1911f99c873014b30740e303
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix dirty mapping checking in passthrough mode switching As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/01b22656d8a68dbeae59f8b80866e7b11936b20a
- https://git.kernel.org/stable/c/12105c7f18375d7615dad7605d89eadae7eb12a6
- https://git.kernel.org/stable/c/1443c32f24d6d8bcdf4beceef2afc09290b98717
- https://git.kernel.org/stable/c/21c503d60a257e54ca3ac58e2721bd24501d5bde
- https://git.kernel.org/stable/c/322586745bd1a0e5f3559fd1635fdeb4dbd1d6b8
- https://git.kernel.org/stable/c/5c98a3f1d7a554c9e920aa31daf92af6b5bbb8cc
- https://git.kernel.org/stable/c/bd5a2c1018938e6b32670728bdb32a3f0efff00f
- https://git.kernel.org/stable/c/c2e86f647561fcf5e1c6eba7d75e9e0c4299c94d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: fix missing locks in invalidating cache blocks In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted"
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1b2bec4a7dcf5f00b7a1cbeeec8997841d783513
- https://git.kernel.org/stable/c/2b62d0611c9af14a16bddf22df2612b4f40eb5a1
- https://git.kernel.org/stable/c/2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45
- https://git.kernel.org/stable/c/4991b5a08751e2e82488fb93ae08849b6aea10d9
- https://git.kernel.org/stable/c/93627a29d4b66d4a2def938dfb8610cc80ae454b
- https://git.kernel.org/stable/c/9a5fdfb9e57ec3a8ad2b8fce5e5ffa42d53b130e
- https://git.kernel.org/stable/c/ac5ee99443891bdb161f5539606a66a1b5e72542
- https://git.kernel.org/stable/c/c348ae47d8e65f06429fa41adce9ad986b696766
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix write hang in passthrough mode The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/05798d091ebcfb6d68228890e593f209e8ac940d
- https://git.kernel.org/stable/c/4ca8b8bd952df7c3ccdc68af9bd3419d0839a04b
- https://git.kernel.org/stable/c/64d6519b00be4116d365bd31f33a5e5ce2944c1a
- https://git.kernel.org/stable/c/9fa18d0b981776b190ca4632942a7c2174052b78
- https://git.kernel.org/stable/c/b8ace9e96983abb20ccf39edce8a60f1bb0b83d8
- https://git.kernel.org/stable/c/ecb10c193cbebf5e6984246a9b4ff1f95d45ed87
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix null-deref with concurrent writes in passthrough mode
In passthrough mode, when dm-cache starts to invalidate a cache
entry and bio prison cell lock fails due to concurrent write to
the same cached block, mg->cell remains NULL. The error path in
invalidate_complete() attempts to unlock and free the cell
unconditionally, causing a NULL pointer dereference:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT
RIP: 0010:dm_cell_unlock_v2+0x3f/0x210
Call Trace:
invalidate_complete+0xef/0x430
map_bio+0x130f/0x1a10
cache_map+0x320/0x6b0
__map_bio+0x458/0x510
dm_submit_bio+0x40e/0x16d0
__submit_bio+0x419/0x870
Reproduce steps:
1. Create a cache device
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 262144 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
2. Promote the first data block into cache
fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \
--direct=1 --size=64k
3. Reload the cache into passthrough mode
dmsetup suspend cache
dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"
dmsetup resume cache
4. Write to the first cached block concurrently
fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \
--randrepeat=0 --direct=1 --numjobs=2 --size 64k
Fix by checking if mg->cell is valid before attempting to unlock it.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/01264a6a3a3ad7ac1d73443299cd5a9568002454
- https://git.kernel.org/stable/c/0aa745fea1f8dc81bcdd0a45e215b6706727b482
- https://git.kernel.org/stable/c/25dcc1989c194ba2b5fb6d03cbb9b83814ac0d15
- https://git.kernel.org/stable/c/7d1f98d668ee34c1d15bdc0420fdd062f24a27c0
- https://git.kernel.org/stable/c/a2635d541a93fd111e743cf14b6275dc81be2abc
- https://git.kernel.org/stable/c/c7fb6bc864c4910b344dafa36dd5028e9b980768
- https://git.kernel.org/stable/c/df3b8ef06cc62de4fca5d2108e285085b3cffd44
- https://git.kernel.org/stable/c/ee38fb00e1a80f46a4990e38f25ecb04ae7b7417
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: use managed regmap_field allocations The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/002a5f925d42eca8ad547e55a4ae22714cfe9dec
- https://git.kernel.org/stable/c/1696fad8b259a2d46e51cd6e17e4bcdbe02279fa
- https://git.kernel.org/stable/c/43b67761d486d719128e164536e58de5a81dff9b
- https://git.kernel.org/stable/c/4b8dba4527727623a97948aff9f0969a14c203a9
- https://git.kernel.org/stable/c/7422a11a753daacbc2409513cf65e1de0d17c291
- https://git.kernel.org/stable/c/9641071e3a8e0bc664477a0e54db5f9815f0fb79
- https://git.kernel.org/stable/c/a3f3c332882c98ae7553af372191116d1384ca52
- https://git.kernel.org/stable/c/c3af3bcfc1deb3b230cc266a2ac75bca8f4dfba9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: backend: fix error pointer dereference The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR()
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/06277983eca4a31d3c2114fa33d99a6e82484b11
- https://git.kernel.org/stable/c/47038159c559824f4dbfb5b0d87b9b3416663372
- https://git.kernel.org/stable/c/779c2f10743fc021f2f0ebe2b188cadfb973c5e4
- https://git.kernel.org/stable/c/cf615b90a11a39a28e313be5e508e94bcde72016
- https://git.kernel.org/stable/c/e9bef62f1bb9fcb38223730657af20f4c6283c16
- https://git.kernel.org/stable/c/ea51fd96aca01381e8f1ac0c671a57b7619193bb
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/komeda: fix integer overflow in AFBC framebuffer size check The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/02ff8a7d3d0eecc546b9ab4c07b3d7c65d485583
- https://git.kernel.org/stable/c/779ec12c85c9e4547519e3903a371a3b26a289de
- https://git.kernel.org/stable/c/8165e8b28fdf392c2c7412518d602b4f193812a8
- https://git.kernel.org/stable/c/872d923b852705054bc099af663da862fdc1097d
- https://git.kernel.org/stable/c/a3a2a9bdc0f9c2d863a5a290cb2d4a565f7268e7
- https://git.kernel.org/stable/c/d8a541906860aa3519b1874780d933c766918a7c
- https://git.kernel.org/stable/c/e27b58095d7d3ac72f230e318838dee956258460
- https://git.kernel.org/stable/c/fe1f80f8f6e8611ac6349b9d464e8750443390cf
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/183128da0406b1c10e6f60b7b9fe70788b9c8c1d
- https://git.kernel.org/stable/c/1921f91298d1388a0bb9db8f83800c998b649cb3
- https://git.kernel.org/stable/c/3128b294b426533c8d9162187446d93a8a160359
- https://git.kernel.org/stable/c/7bad93e99737e4a5c0c14ac50c05152cf4e28022
- https://git.kernel.org/stable/c/866d3d9b87751b1944168fd82615505e0c0fd6cf
- https://git.kernel.org/stable/c/acbf45bd584d924b320bee2a7fe2a26f64904d95
- https://git.kernel.org/stable/c/ea690b3b6e58ae00979af8195b4cc24df466b65e
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0ccd75c51f620374086f359e906917676e699a1c
- https://git.kernel.org/stable/c/330b20ec97916961ee0e6c29c06bc0fa7c96e64c
- https://git.kernel.org/stable/c/42776497cdbc9a665b384a6dcb85f0d4bd927eab
- https://git.kernel.org/stable/c/5501d055a1ce3c747141e3955ba8cf034d193f3e
- https://git.kernel.org/stable/c/77a853aec710b2fdf41fa298ea3cbc9a4358f917
- https://git.kernel.org/stable/c/96dca51715d86559ed6ed8028e5445cecb80f3ae
- https://git.kernel.org/stable/c/dc89961b76f12aff47124c1df4bdb32a080f4d0c
- https://git.kernel.org/stable/c/fe1188abdae9b7a8199dcdfcf9244d5e5d61eb14
- https://access.redhat.com/errata/RHSA-2026:42550
- https://access.redhat.com/errata/RHSA-2026:42552
- https://access.redhat.com/errata/RHSA-2026:42919
- https://access.redhat.com/errata/RHSA-2026:43307
- https://access.redhat.com/security/cve/CVE-2026-53071
- https://bugzilla.redhat.com/show_bug.cgi?id=2492458
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53071.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/385b2d0468a0871fc716c549fa3b0c257c7dbcb3
- https://git.kernel.org/stable/c/541d5bf9b5afaf41090b2a3aa7b47f2db2ff801f
- https://git.kernel.org/stable/c/5c7209a341ff2ac338b2b0375c34a307b37c9ac2
- https://git.kernel.org/stable/c/60e3f4ff02d1f2d55bfbf2ca32a97285a9771ee4
- https://git.kernel.org/stable/c/6b4d226d01ab7da0d2027a2a1e3a6079152e5065
- https://git.kernel.org/stable/c/9d4a6c0f43fc5e4d4f062e8e450e5483eb74176e
- https://git.kernel.org/stable/c/c27224daf0b08efbb2b24ed64b6139b294f5473a
- https://git.kernel.org/stable/c/c7777f534a8018ae4bb1c80d8925af4df588a314
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/194f029a4d7f739e44ebc1f473120187b4de5104
- https://git.kernel.org/stable/c/356dee1bcac4d0d9152390561fa63331ebff211b
- https://git.kernel.org/stable/c/3daa5818e473ed60eb69d8b5c71b651909d28c5a
- https://git.kernel.org/stable/c/68d39ea5e0adc9ecaea1ce8abd842ec972eb8718
- https://git.kernel.org/stable/c/a673cf6c4ac702cb79ac1f4d7fc4de763a6a3e40
- https://git.kernel.org/stable/c/ebb39b2d81731b83ee71a1ba6dd0291a57b5ac07
- https://git.kernel.org/stable/c/ed4033fb85ccaaf6c3983be3c7b037e48253d232
- https://git.kernel.org/stable/c/f4b69c35813c432973d340d3600c01de106ed474
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a04db240effd85773f66244645a28cedddb72d2
- https://git.kernel.org/stable/c/12bec2bd4b76d81c5d3996bd14ec1b7f4d983747
- https://git.kernel.org/stable/c/1f882c492d46f90bdb36f4936876c88c28dab21c
- https://git.kernel.org/stable/c/6a9f38d5ff11e00bc54baab752642978805e81eb
- https://git.kernel.org/stable/c/6def5fe753cbe5b279ee5fd10327b2611cbddaca
- https://git.kernel.org/stable/c/7254267799d083280c0e53effc101a33add95f7b
- https://git.kernel.org/stable/c/8042240412de3222d27b31e89d29336961cad9e4
- https://git.kernel.org/stable/c/e6aa481f21fc7a41ed344767ea25aae9d03fae71
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1a8a51ce85075a56a743b6f142606dd2696a391c
- https://git.kernel.org/stable/c/2bb6379416fd19f44c3423a00bfd8626259f6067
- https://git.kernel.org/stable/c/3b2c2157dc2afc5c17cd7238afefca92f1ef330e
- https://git.kernel.org/stable/c/5013be175c7ffd8b39efbc3c9c4db5b10b85fea8
- https://git.kernel.org/stable/c/5080e188c914110034bbc569d5cfa2f06204681d
- https://git.kernel.org/stable/c/67e901e28d177ac9a9bed76d69ce3471e704a89e
- https://git.kernel.org/stable/c/954745d0223e7caec917c0b2d1a889ff56fa6e54
- https://git.kernel.org/stable/c/c9edd90c57ae23692fff6b049fdfa4572a9fd532
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix OOB in pcpu_init_value An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes. The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1 pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/576afddfee8d1108ee299bf10f581593540d1a36
- https://git.kernel.org/stable/c/6086079e6d1c32ba4c4b422612b8aebb1129a96c
- https://git.kernel.org/stable/c/634a793d0e1c822412095d25a1338f8831ad894c
- https://git.kernel.org/stable/c/e0378419b0e20178b5d100b27c9cc7e51064202e
- https://git.kernel.org/stable/c/e19c5ed9f1922a6854073f8651a63fa7be26e9e9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/rds: Restrict use of RDS/IB to the initial network namespace Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/07035306bf722f4676a1aee35cbeb3732c76194e
- https://git.kernel.org/stable/c/3174fc703d081d2ca538b22fba734e3ad5b52322
- https://git.kernel.org/stable/c/3e7f14cd5a51533404e1ae4809caab46073fb5c7
- https://git.kernel.org/stable/c/a7494479757d60d2413bfaa087f8431a26eea032
- https://git.kernel.org/stable/c/b6a54f5e9ce9b97ae641855378d71c5154a085c0
- https://git.kernel.org/stable/c/c244b79adffad89a5173cf8bfaa06a6b40bbd09b
- https://git.kernel.org/stable/c/ebf71dd4aff46e8e421d455db3e231ba43d2fa8a
- https://git.kernel.org/stable/c/fb407343c0c16e94584707b2dfdd350a5f81b000
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/13c02881e49aac4c82b261faa26db9edf2567231
- https://git.kernel.org/stable/c/2f2ec8e7730e21fc9bd49e0de9cdd58213ea24d0
- https://git.kernel.org/stable/c/691adf738817275368ed56311b7d798d617823a3
- https://git.kernel.org/stable/c/7d73c72cccac651acc891377a5e623e4021c6380
- https://access.redhat.com/security/cve/CVE-2026-53081
- https://bugzilla.redhat.com/show_bug.cgi?id=2492322
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53081.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1d3abf0c3ddeefc6f6d913aa129acc06fce8240a
- https://git.kernel.org/stable/c/2951656b0de00153f2687f3a093890bce72b6215
- https://git.kernel.org/stable/c/578f3aba427c938fecfa0d8c83d9acb213a9b24a
- https://git.kernel.org/stable/c/987af7625ceb1ee59d70eb0abd7af11c75e45d79
- https://git.kernel.org/stable/c/bf9a38803b2626b01cc769aaf13485d8650f576f
- https://git.kernel.org/stable/c/d4cceb5184538613572fb79319453f281b1eeacb
- https://git.kernel.org/stable/c/d9ce2a4b679122397d7f35bad7be46913ad1ca80
- https://git.kernel.org/stable/c/e9cf4018d74237d142cd66243c821d13593270f0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix RCU stall in bpf_fd_array_map_clear()
Add a missing cond_resched() in bpf_fd_array_map_clear() loop.
For PROG_ARRAY maps with many entries this loop calls
prog_array_map_poke_run() per entry which can be expensive, and
without yielding this can cause RCU stalls under load:
rcu: Stack dump where RCU GP kthread last ran:
CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef)
Workqueue: events prog_array_map_clear_deferred
RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246
Call Trace:
prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096
__fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925
bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline]
prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141
process_one_work+0x898/0x19d0 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x770/0x10b0 kernel/workqueue.c:3400
kthread+0x465/0x880 kernel/kthread.c:464
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4406942e65ca128c56c67443832988873c21d2e9
- https://git.kernel.org/stable/c/67bdb4b0d26f2d6bbf1798a925ef5a3b9ed7357a
- https://git.kernel.org/stable/c/71ddb7defc442ab38c53123c384fedbfd8410a15
- https://git.kernel.org/stable/c/b1f7158a86f3cbac4d5a32beb55ca0f8027d44cd
- https://git.kernel.org/stable/c/e1ed678855e315f90c70c1723e94157a9a82e660
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: return VMA snapshot from task_vma iterator Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: fix mm lifecycle in open-coded task_vma iterator The open-coded task_vma iterator reads task->mm locklessly and acquires mmap_read_trylock() but never calls mmget(). If the task exits concurrently, the mm_struct can be freed as it is not SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free. Safely read task->mm with a trylock on alloc_lock and acquire an mm reference. Drop the reference via bpf_iter_mmput_async() in _destroy() and error paths. bpf_iter_mmput_async() is a local wrapper around mmput_async() with a fallback to mmput() on !CONFIG_MMU. Reject irqs-disabled contexts (including NMI) up front. Operations used by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async) take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from NMI or from a tracepoint that fires with those locks held could deadlock. A trylock on alloc_lock is used instead of the blocking task_lock() (get_task_mm) to avoid a deadlock when a softirq BPF program iterates a task that already holds its alloc_lock on the same CPU.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/239cec25a22662dbd80f57d94b38178c8be95269
- https://git.kernel.org/stable/c/43683bb280330f3d36f0f2a3932a4867b9603e9c
- https://git.kernel.org/stable/c/d0862de7c866c5bd7c32531f66738c21197af888
- https://git.kernel.org/stable/c/d8e27d2d22b6e2df3a0125b8c08e9aace38c954c
- https://access.redhat.com/security/cve/CVE-2026-53085
- https://bugzilla.redhat.com/show_bug.cgi?id=2492404
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53085.json
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/5393b2b5bee2ac51a0043dc7f4ac3475f053d08d
- https://git.kernel.org/stable/c/681fdfe823b4f1036ed50b58b8838c7917ea389c
- https://git.kernel.org/stable/c/7ce1c26aac3b318886a57425f64b522da7389153
- https://git.kernel.org/stable/c/c270e2bec3e55a716d25c35341091339457ac883
- https://git.kernel.org/stable/c/e8206538cbaf4f4068e99a4cb1138690a1e00499
- https://git.kernel.org/stable/c/e85b0c0a12e967930044608311471b665baa315c
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix off-by-one in bcmgenet_put_txcb The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/14e9f86564fff7bcf7f45c1b69080e837b31d185
- https://git.kernel.org/stable/c/29394f722f620281f2ee9a47f947734e53d72c90
- https://git.kernel.org/stable/c/2a74590170427a3ca7cc4bb8690cdd559129c29c
- https://git.kernel.org/stable/c/4cab761fc51c65aef741fcece4a18f3554edbc09
- https://git.kernel.org/stable/c/57f3f53d2c9c5a9e133596e2f7bc1c50688a6d38
- https://git.kernel.org/stable/c/72df896e31ddd06fcc5a789f025ad7a62a18bc9b
- https://git.kernel.org/stable/c/85f34ec320d3881badfd4edc5fee5cd5012bb54d
- https://git.kernel.org/stable/c/fb9a3c1f547d0ff024dbfe7b6f327626ddf0a3de
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix error pointer dereference The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() [add missing wifi: prefix]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2e0e5a43ed126f896a4ad31ade66c90270601bae
- https://git.kernel.org/stable/c/334c68750eee84c2327db1d152be83ff5ad8e20b
- https://git.kernel.org/stable/c/99ef547659178eef6d6ba4738a9d989ce90cf909
- https://git.kernel.org/stable/c/a3b45090a91e2f0b9715870d8f8d9ca2fdfbc1af
- https://git.kernel.org/stable/c/bd6c906e0c4af6d5d0c49c3c4ee090b4913da17d
- https://git.kernel.org/stable/c/cbea71b4480394708f9a6e007a0385acfe5e1ec8
- https://git.kernel.org/stable/c/d3f280be48f1c672cb10e8026c236d0cca60048a
- https://git.kernel.org/stable/c/dd8592fc6007a451c3e4b9025de365e39de8178a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stale offload->prog pointer after constant blinding When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync. Fix this by updating offload->prog in bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/059525cf18e69a9313baf947d8898c6ee7ca6b65
- https://git.kernel.org/stable/c/25484c39d1ec82a0368798d956da3de5039b3fe8
- https://git.kernel.org/stable/c/a1aa9ef47c299c5bbc30594d3c2f0589edf908e6
- https://git.kernel.org/stable/c/a713b72ff88cdab4d5d692908ab1259ada511f4d
- https://git.kernel.org/stable/c/c79f8503d83d4665be461fb9e45e215d0380c67b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/4a3d0fe30b907ff324b1b49756f7e713d67f3645
- https://git.kernel.org/stable/c/571a05ea1baaccc0dc1e0d227b2cbc978b96d392
- https://git.kernel.org/stable/c/7027e705062482a8cea43a1c13ede3c35653966f
- https://git.kernel.org/stable/c/8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19
- https://git.kernel.org/stable/c/b089aa6e94d7a08e74d076a0fe274842dc9feccc
- https://git.kernel.org/stable/c/cb2c1f3cf65b855548e1b8d55a08bfbaa5a0901a
- https://git.kernel.org/stable/c/d4c4bd231ebad70e6f30db429e9640bf378b2f52
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1146d0946b5358fad24812bd39d68f31cd40cc34
- https://git.kernel.org/stable/c/21ce6d867867645fff0ef657be18f61d9f39dcd8
- https://git.kernel.org/stable/c/6b7cbb13c838cf2a5f2e7be0e96fe15250087939
- https://git.kernel.org/stable/c/6d5202409467d621b6d1dfd7fc7dadb997fe66d2
- https://git.kernel.org/stable/c/e6856af8a22a8e2cd18241a465ed00c2301b3a5e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to avoid a potential kernel panic in scenarios where `vif` might not be initialized.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Zero-extend bpf prog return values and kfunc arguments s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/202e42e4aa890172366354b233c42c73107a3f59
- https://git.kernel.org/stable/c/366b0e05ee24f5ba62bdc7ec1346038258b9a797
- https://git.kernel.org/stable/c/44c4f999b03f55debb1a0c5ab5c1796895a1adf8
- https://git.kernel.org/stable/c/834918a77be51419383bf1dda9f02b81ecf26b34
- https://git.kernel.org/stable/c/edc90a12073b9a530064a99945c183dde120cb99
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap
The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to
calculate the needed headroom:
err = skb_cow_head(skb,
len + LL_RESERVED_SPACE(skb_dst(skb)->dev));
But skb->_skb_refdst may not be initialized when the skb is set up by
bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function
in this scenario will trigger null pointer dereference, causing a kernel
crash as Yinhao reported:
[ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 105.186382] #PF: supervisor read access in kernel mode
[ 105.186388] #PF: error_code(0x0000) - not-present page
[ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0
[ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1
[ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520
[ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0
[ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246
[ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00
[ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500
[ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000
[ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98
[ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002
[ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000
[ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0
[ 105.186499] PKRU: 55555554
[ 105.186502] Call Trace:
[ 105.186507]
[ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40
[ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49
[ 105.186536] ? kvm_clock_get_cycles+0x18/0x30
[ 105.186547] ? ktime_get+0x3c/0xa0
[ 105.186554] bpf_test_run+0x195/0x320
[ 105.186563] ? bpf_test_run+0x10f/0x320
[ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0
[ 105.186590] __sys_bpf+0x69c/0xa40
[ 105.186603] __x64_sys_bpf+0x1e/0x30
[ 105.186611] do_syscall_64+0x59/0x110
[ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0
[ 105.186649] RIP: 0033:0x7f166a97455d
Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/5500913516e071dbe23e5a404c861dd2d82c9589
- https://git.kernel.org/stable/c/599905c3f10bb83e6e6881d5a7f5cea5df07dc23
- https://git.kernel.org/stable/c/5c8d1f91fc4898d79f29d79c1a6f7c2b3ee66fb0
- https://git.kernel.org/stable/c/94f95328b9070909b5b875c647b17a11d3d85567
- https://git.kernel.org/stable/c/972787479ee73006fddb5e59ab5c8e733810ff42
- https://git.kernel.org/stable/c/c7ad31fb948fdd4905263f4324160682c3fa7bc6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/008c456b76e9070979bc0e763897a5d3b0fdd4dc
- https://git.kernel.org/stable/c/039cd522dc70151da13329a5e3ae19b1736f468a
- https://git.kernel.org/stable/c/3c0e8a3179e6325a7dc6ce221aef0e03d854ab4b
- https://git.kernel.org/stable/c/7731b67bd59d1284d150cbe40a47e95a10613234
- https://git.kernel.org/stable/c/aa10a452e34810987fb9f4a047995b30003fb53f
- https://git.kernel.org/stable/c/ae10d4a1ab6bcaa1336abb171908a9a365761d3e
- https://git.kernel.org/stable/c/e40873820c9d245ce482faa7ad514ebdb3b8d23d
- https://git.kernel.org/stable/c/fac1079e0fdec6df6d7562c21941587236dc3def
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: s390/cio: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/106d594711e97762788046c5bbb94f580abc4bf4
- https://git.kernel.org/stable/c/2081957d8c323ffb58a10bc64837717ac5a042a1
- https://git.kernel.org/stable/c/ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4
- https://git.kernel.org/stable/c/b660ba045b2b22cf3b4be72773de00cb48f47be5
- https://git.kernel.org/stable/c/c4295487124f461405e1ef64dfa8c4ab0cb7ebcf
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: platform/wmi: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: PCI: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between reflink and transaction commit when using flushoncommit
When using the flushoncommit mount option, we can have a deadlock between
a transaction commit and a reflink operation that copied an inline extent
to an offset beyond the current i_size of the destination node.
The deadlock happens like this:
1) Task A clones an inline extent from inode X to an offset of inode Y
that is beyond Y's current i_size. This means we copied the inline
extent's data to a folio of inode Y that is beyond its EOF, using a
call to copy_inline_to_page();
2) Task B starts a transaction commit and calls
btrfs_start_delalloc_flush() to flush delalloc;
3) The delalloc flushing sees the new dirty folio of inode Y and when it
attempts to flush it, it ends up at extent_writepage() and sees that
the offset of the folio is beyond the i_size of inode Y, so it attempts
to invalidate the folio by calling folio_invalidate(), which ends up at
btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it
tries to lock the folio's range in inode Y's extent io tree, but it
blocks since it's currently locked by task A - during a reflink we lock
the inodes and the source and destination ranges after flushing all
delalloc and waiting for ordered extent completion - after that we
don't expect to have dirty folios in the ranges, the exception is if
we have to copy an inline extent's data (because the destination offset
is not zero);
4) Task A then attempts to start a transaction to update the inode item,
and then it's blocked since the current transaction is in the
TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the
current transaction to become unblocked (its state >=
TRANS_STATE_UNBLOCKED).
So task A is waiting for the transaction commit done by task B, and
the later waiting on the extent lock of inode Y that is currently
held by task A.
Syzbot recently reported this with the following stack traces:
INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: writeback wb_workfn (flush-btrfs-46)
Call Trace:
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x1553/0x5240 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7008
wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]
btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914
btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]
btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704
extent_writepage fs/btrfs/extent_io.c:1852 [inline]
extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]
btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713
do_writepages+0x32e/0x550 mm/page-writeback.c:2554
__writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750
writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042
wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227
wb_do_writeback fs/fs-writeback.c:2374 [inline]
wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INFO: task syz.4.64:6910 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.4.64 state:D stack:22752 pid:6910 tgid:
---truncated---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md: wake raid456 reshape waiters before suspend During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/000e8454692cab9d1f1b80130e2870e355301d06
- https://git.kernel.org/stable/c/23308af722fefed00af5f238024c11710938fba3
- https://git.kernel.org/stable/c/4048ed98860d3785645ebbd34f69566a6c7320c3
- https://git.kernel.org/stable/c/73a5af059905d171b398c8b2381632ee499948b5
- https://git.kernel.org/stable/c/b3e005f16cd98f815429a87aef4c61e9c140779f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drbd: Balance RCU calls in drbd_adm_dump_devices() Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1f112240531f0a0b437b2e001c1d89e8b25a8328
- https://git.kernel.org/stable/c/282e06e6d494a7bee85af78c747527b7d4009cc3
- https://git.kernel.org/stable/c/2b31e86387e60b3689339f0f0fbb4d3623d9d494
- https://git.kernel.org/stable/c/68ebb9183ac3621b96b18e046841eadb9508783c
- https://git.kernel.org/stable/c/6cd27bcb71bb73f955d104cc3a62be6f83724392
- https://git.kernel.org/stable/c/8092713a10c19fa0f731b71b2853af4319ca54fd
- https://git.kernel.org/stable/c/996d279f2c985d771d6cfdd923e447d825726e06
- https://git.kernel.org/stable/c/ae12bb44b392637a8321ade305c883f9ffc0daea
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/mbcache: cancel shrink work before destroying the cache mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize < OMFS_DIR_START causes an unsigned underflow there, wrapping to a value near 2^32. That drives a ~4 GiB memset() from bh->b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0621c385fda1376e967f37ccd534c26c3e511d14
- https://git.kernel.org/stable/c/131ea3e57fc22936ed0e2c8330f2e36106172f51
- https://git.kernel.org/stable/c/5822a05a841a10794ad818620dd2af490b0705d3
- https://git.kernel.org/stable/c/6561afc38398e3518a29c5eebb975c30468f98a6
- https://git.kernel.org/stable/c/754ff1bea3819a90c6f33cccfc1a299ef7609f07
- https://git.kernel.org/stable/c/79f84af38c9fef9deb0e02c79eb969b5541c2644
- https://git.kernel.org/stable/c/817f16ed62bc58a168417bfb5e859c2a370bab03
- https://git.kernel.org/stable/c/fbc72f5c645155dc2ed3573243ed20f9913e3a54
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/gma500/oaktrail_lvds: fix hang on init failure The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4e04b564c005c9900643c56656d751ad677889be
- https://git.kernel.org/stable/c/5fe9f505d8578852c30668567bc3ce52e776e8c7
- https://git.kernel.org/stable/c/657a091ab6d01d0091b77660c75cfed573c9a53e
- https://git.kernel.org/stable/c/7877f7e231a8bd5c817af1491276550a5e195cd7
- https://git.kernel.org/stable/c/ab9256936b58eb178caddcf5b5b1638f079909d2
- https://git.kernel.org/stable/c/f6fc44af3bbd5ab0fb6bdec6f47decca11b38425
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: audit: fix incorrect inheritable capability in CAPSET records __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a065c51a225854768b772a0b733a44d77162582
- https://git.kernel.org/stable/c/151ee470edc3d7ed29fe72df678f8357d2ad8ced
- https://git.kernel.org/stable/c/75bd76c9eb2de9afeca03dc5152ebca5fb8fc816
- https://git.kernel.org/stable/c/95de7bb4bf535a9288549d401ebde83cdcbf2792
- https://git.kernel.org/stable/c/d782e4d200cd9036ef353eeb29525bfbfd13a14e
- https://git.kernel.org/stable/c/e35f3550c5b4fab33103c18654c293cee9850b0a
- https://git.kernel.org/stable/c/e4a640475e43f406fdfd56d370b1f34b0cbbc18d
- https://git.kernel.org/stable/c/febb4bf373ac565d3fb8d1f429827bdd983be496
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: arm64: Reserve an extra page for early kernel mapping The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_reset_all_vfs() ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi(). When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0]. The single-VF reset path in ice_reset_vf() already handles this correctly by checking the return value of ice_vf_reconfig_vsi() and skipping ice_vf_post_vsi_rebuild() on failure. Apply the same pattern to ice_reset_all_vfs(): check the return value of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and ice_eswitch_attach_vf() on failure. The VF is left safely disabled (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver rebind). Note that this patch does not prevent the VF VSI rebuild from failing during NVM update — the underlying cause is firmware being in a transitional state while the EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer dereference that crashes the kernel when the rebuild does fail. crash> bt PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5" #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595 #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [exception RIP: ice_ena_vf_q_mappings+0x79] RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206 RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000 RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040 R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000 R13: 0000000000000010 R14: R15: ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4 #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663 #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9 The panic occurs attempting to dereference the NULL pointer in RDX at ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi). The faulting VSI is an allocated slab object but not fully initialized after a failed ice_vsi_rebuild(): crash> struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0, rx_rings = 0x0, tx_rings = 0x0, q_vectors = 0x0, txq_map = 0x0, rxq_map = 0x0, alloc_txq = 0x10, num_txq = 0x10, alloc_rxq = 0x10, num_rxq = 0x10, The nvmupdate64e process was performing NVM firmware update: crash> bt 0xff34c9edd1a30000 PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e" #0 [ff72159bcd617618] __schedule at ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 ---truncated---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1e9185b13ce57b86844447e092e58abb3be849b1
- https://git.kernel.org/stable/c/3ad2471e61e9f0c4d25046d08e3d747501c3b0dd
- https://git.kernel.org/stable/c/429024f3a407e4137aee825c2a6be0aba857937d
- https://git.kernel.org/stable/c/4c2ac52eeeb672624b06c7a135301d7b8a21d52e
- https://git.kernel.org/stable/c/54ef02487914c24170c7e1c061e45212dc55365e
- https://git.kernel.org/stable/c/acc76b97902757b63ba5136f787d107647236a19
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/conexant: Fix missing error check for jack detection In cx_probe(), the return value of snd_hda_jack_detect_enable_callback() is ignored. This function returns a pointer, and if it fails (e.g., due to memory allocation failure), it returns an error pointer which must be checked using IS_ERR(). If the registration fails, the driver continues to probe, but the jack detection callback will not be registered. This can lead to a kernel crash later when the driver attempts to handle jack events or accesses the uninitialized structure. Check the return value using IS_ERR() and propagate the error via PTR_ERR() to the probe caller.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1da5c73f3793b224696617a2a21def7500ba18d6
- https://git.kernel.org/stable/c/49c2c5924552e1d2f8b635dee663abebbb7cf63b
- https://git.kernel.org/stable/c/a2a33e87a2ffce3046c574d24eec4390c27c9365
- https://git.kernel.org/stable/c/b0e2333a231107adedd38c6fcfe1adc6162716fc
- https://git.kernel.org/stable/c/d68f753d89f4ef6e410d7e8b7e8ab2fdde921b80
- https://git.kernel.org/stable/c/dd110cc00cf854a8ecd8d003127a4178c28574ea
- https://git.kernel.org/stable/c/f837c7b85143a7c54140ff41ad5c076b73cd9933
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0ef196a208385b7d7da79f411c161b04e97283e2
- https://git.kernel.org/stable/c/5c29d20470d4566d1b68df57097d642d01f8b427
- https://git.kernel.org/stable/c/61957c2e467b39b528a290016367d32a433fa846
- https://git.kernel.org/stable/c/8c4254c8f5836e77ae83e7fc037f02b69f7a0977
- https://git.kernel.org/stable/c/a31c3feb54b15a90232e497ad0e27e8a82052d8d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: don't free the reused channel The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/240c71a2aea36a1a4210f911a1c32ea88777e8e4
- https://git.kernel.org/stable/c/3afca89fae501dbd7421e1777b5b8f033b1d98d0
- https://git.kernel.org/stable/c/5c209299b0113e289e238fa5f2e8f00c59f76060
- https://git.kernel.org/stable/c/5d4f3d0f64f1016cb78b400a70b67df91fac99b5
- https://git.kernel.org/stable/c/82f6dcea46cf5de65c4ba7283f7c7b34de4a324d
- https://git.kernel.org/stable/c/88ebadbf0deefdaccdab868b44ff70a0a257f473
- https://git.kernel.org/stable/c/c494a11da45ad7ec9b0ff216c3e3ace351193bb6
- https://git.kernel.org/stable/c/fc0089f82c3e36060c2c79156bc2018bfb16b56b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mailbox: add sanity check for channel array Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0f11444271110d9b5bc6316a153c6431abda899c
- https://git.kernel.org/stable/c/14aed0d4e58389cc6a88acf8610b12d3e476272b
- https://git.kernel.org/stable/c/37792091ab28ba030fd8d61184c47d4d51294170
- https://git.kernel.org/stable/c/5cc3300fab262b26c28bc2fc06df693410c3840b
- https://git.kernel.org/stable/c/6362c4a7d7e21e68cd9aa04df7cde16befba3a4b
- https://git.kernel.org/stable/c/9dd7489943324298bb0f385495795a82f1dd6507
- https://git.kernel.org/stable/c/c1aad75595fb67edc7fda8af249d3b886efa1be9
- https://git.kernel.org/stable/c/d44872a569b8fbacde457ff2587a775e5004bb79
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: free channels on probe error On probe error, free the previously obtained channels. This not only prevents a leak, but also UAF scenarios because the client structure will be removed nonetheless because it was allocated with devm.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/02beb178e2e159daeb8f992d7abb16a37da31664
- https://git.kernel.org/stable/c/0ad8c4a03a358de7811ba1ab8cbd1fe76ad0ff6b
- https://git.kernel.org/stable/c/15c4cc3850cfe1b973eb7b63c02314b267f06a64
- https://git.kernel.org/stable/c/187069ccc3474516af32350e20d7e449160fa6de
- https://git.kernel.org/stable/c/6c6ce2ccb4fcf1617fec83f91b21aa0265f30701
- https://git.kernel.org/stable/c/742001919653e7313b4e91780c5d108be1692365
- https://git.kernel.org/stable/c/81c9e7e4030e71391ab479c4c6e17b64802577aa
- https://git.kernel.org/stable/c/c02053a9055d5fdfd32432287cca8958db1d5bc5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4b3a1bf4c2ffd4c9595d900ead78c9035894a025
- https://git.kernel.org/stable/c/5909bedbed38c558bee7cb6758ceedf9bc3a9194
- https://git.kernel.org/stable/c/cea15f66b7b68b2c50943a6660e0692c6635e4eb
- https://git.kernel.org/stable/c/d0e877810baf613b018fd9747440b9d4d9db1428
- https://git.kernel.org/stable/c/d3ff0c121bbaef026df6248ab7ef6f0b068b0647
- https://git.kernel.org/stable/c/ea3ab43a1f3cf2c7cecd75c8be1ee99a5e94a92e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Resolve soft lockup issue when opening /dev/sgX The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1afd963fcd963db0dc5d47df6dfcf010c9c4647e
- https://git.kernel.org/stable/c/3d74e0654ac908c65a8f20373091826fe43b1363
- https://git.kernel.org/stable/c/9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202
- https://git.kernel.org/stable/c/c47ccfb3d80dfed522ca06a5954ac97488d78c5a
- https://git.kernel.org/stable/c/c5f4a211e82d04ccc1809311322c47023bbe66e2
- https://git.kernel.org/stable/c/d06a310b45e153872033dd0cf19d5a2279121099
- https://git.kernel.org/stable/c/fe671d3c84ffb1b763d590c25195755adeaadaba
- https://git.kernel.org/stable/c/feade299e932967de27519338d41de348fb5b061
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tty: hvc_iucv: fix off-by-one in number of supported devices MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/11207e42a332eb8bbcb9fe74df9edd2a807c5607
- https://git.kernel.org/stable/c/3104a3f40feb107f77d7116ad9bf6c210ab7babf
- https://git.kernel.org/stable/c/3d3b89e6ab93bdd0efd45828bda6b0e61cc46dff
- https://git.kernel.org/stable/c/484357dff256c816d9466bda35eb765685e4dc86
- https://git.kernel.org/stable/c/a76511bc654819425d3b15e77b523d7f9d81f064
- https://git.kernel.org/stable/c/f1dc8e72de9aabe5d96767a4e97219ac26b79fe5
- https://git.kernel.org/stable/c/f2a880e802ad12d1e38039d1334fb1475d0f5241
- https://git.kernel.org/stable/c/fed8b8f33a46db0ee2efdb000f4f630c86ed8ca4
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/01b61e8dda9b0fdb0d4cda43de25f4e390554d7b
- https://git.kernel.org/stable/c/1fb7f356547d9688822315cd2b205ff0bd5429b4
- https://git.kernel.org/stable/c/2a0673836f019e7c032acbf48d022d5ccf02a845
- https://git.kernel.org/stable/c/426cd8eedac89b86148d4478990eeef16e8a2520
- https://git.kernel.org/stable/c/760ab35040aca8399021fdb9ff1db1089feb7194
- https://git.kernel.org/stable/c/819d8ebad3200a53de99bd7e297bc428e41ced54
- https://git.kernel.org/stable/c/c60a2710b73838d250cda57344c049b89abc5d52
- https://git.kernel.org/stable/c/d5403ae28085761d58b555645bc7d5feadb10073
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/3e6c08dd97dcd22a00aee469e0adfa819071d80e
- https://git.kernel.org/stable/c/5a9f29a3e076b637d2234093e57989cf755ded5b
- https://git.kernel.org/stable/c/65dae8b34f0810f3fa9f77c4c63650cd20820693
- https://git.kernel.org/stable/c/9afe53f14a2aae8c4beb30e5ea51641a34f1a3d3
- https://git.kernel.org/stable/c/a6d44f477000c6352de6b05e9e276e62083e5fbf
- https://git.kernel.org/stable/c/c8c4a2972f83c8b68ff03b43cecdb898939ff851
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Place upper limit on station AID Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for 'sta' before dereferencing it to prevent a possible crash.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/4525658002be3ad310b16bf8db48c8adb6a55d32
- https://git.kernel.org/stable/c/65e07964b4b2daf9a54e686cf0fa72d74a9648a8
- https://git.kernel.org/stable/c/94094e70fe292c9566502772d4d4d6d6a99204b1
- https://git.kernel.org/stable/c/9472d37799a0b9ff9b99639f35961ac2f0b3c9be
- https://git.kernel.org/stable/c/b88f905d4449b70da6bda547be546e365e44352e
- https://git.kernel.org/stable/c/be3e5d10643d3be1cbac9d9939f220a99253f980
- https://git.kernel.org/stable/c/e0a0c4903cbba351f0f5b5d104960d3a5b23202f
- https://git.kernel.org/stable/c/e5ff0ba4b6983cdbcc826efc201e7179ece5d46f
HIGH8.0
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.
CVSS 3.xВЫСОКАЯ 8.0
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/407217734835d21d4e0105ebf347860dc1806f88
- https://git.kernel.org/stable/c/5d86d2f1b4d9a508c441d3e45277ae1a73cfed57
- https://git.kernel.org/stable/c/751de6ec671fe75ad9cf65a0638d2a06b6a5984d
- https://git.kernel.org/stable/c/7eebd4c2c86f573af87ff165d08a83432eb0b919
- https://git.kernel.org/stable/c/87c543e2f78d0871f271df92dab98901bbd5b6f5
- https://git.kernel.org/stable/c/a5ca86a6097a8b030ca3226cd300b17ed330f966
- https://git.kernel.org/stable/c/ab1513597c6cf17cd1ad2a21e3b045421b48e022
- https://git.kernel.org/stable/c/added1213395071470a900cc845a042fb51882a6
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix negative tt_buff_len batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_other_tt_response().
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/32edd2a28e112064020a2f319a8cb8a9e5a09767
- https://git.kernel.org/stable/c/33e5ede7ce6d92e531920d4bbd6d3e18ef1c6430
- https://git.kernel.org/stable/c/3c96dff00998314983b68a3e7caac07a66ebe496
- https://git.kernel.org/stable/c/4c4c2f340f4c27373bfcac8dc5032ce7bb474e47
- https://git.kernel.org/stable/c/4dab98961426d0cf6a1599cda6950b7596ca2fcd
- https://git.kernel.org/stable/c/730de8733dd90f70d7580a9b329b971f8e1474a2
- https://git.kernel.org/stable/c/b64963a2ceeb7529310b6cf253a1e540784422f4
- https://git.kernel.org/stable/c/ed28ead3420c373a7928622f114bc6168075d1e1
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix negative last_changeset_len batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_my_tt_response().
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/179eb62506a02d00370bd6478898cb632e10986c
- https://git.kernel.org/stable/c/22d59c72f4a47ffec121d0610f70d0d70c3c11c8
- https://git.kernel.org/stable/c/55dc41fe8821e9a849e147255ad572bc933a9d15
- https://git.kernel.org/stable/c/6314089acf0ddf64376fdc0b1420695504c73f52
- https://git.kernel.org/stable/c/c424e8519ac78eac5d9f4eecf06208a0d619ec14
- https://git.kernel.org/stable/c/d29abf70c665730e249d2ec8e1402095ae26bcee
- https://git.kernel.org/stable/c/eb235472b52ef36981c5aad330485eaf2382c53b
- https://git.kernel.org/stable/c/fc92cdfcb295cefa4344d71a527d61b638b7bfc4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all() skips its batadv_tp_vars_put(), and batadv_tp_receiver_shutdown() fails to put its own reference as well. Fix this by introducing a new atomic variable receiving that is set to 1 when the receiver is initialized and cleared atomically with atomic_xchg() by whichever side claims it first. Only the side that observes the transition from 1 to 0 is responsible for releasing the tp_vars timer reference, eliminating the uncertainty.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0b1bedf114ea93fef929b31f0d70a9eedcc601de
- https://git.kernel.org/stable/c/297e1bc4a915b7cd3e65a79ed906b23fb3d7aaae
- https://git.kernel.org/stable/c/77098e4bea37af51d3962efa88a5af2ea5e1ac57
- https://git.kernel.org/stable/c/7715c73f33260af724d734c41b794457e9be8dbc
- https://git.kernel.org/stable/c/a9f0bfd624ee8a286d6fd2bf0f796e730efb49b0
- https://git.kernel.org/stable/c/b285bc0a97f43823a4967fb6d286de4c7f53d541
- https://git.kernel.org/stable/c/d078501dde9b57210f1808cdef4b59463d1f5fc8
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: fix use-after-free in orig_node RCU release batadv_mcast_purge_orig() removes entries from RCU-protected hlists but does not wait for an RCU grace period before returning. Concurrent RCU readers may still accesses references to those entries at the point of removal. RCU-protected readers trying to operate on entries like orig->mcast_want_all_ipv6_node will then access already freed memory. Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(), just before the call_rcu() invocation. This ensures RCU readers that were active at purge time have drained before the orig_node memory is reclaimed.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/20c2d6a20ca936f5aaa6dd40f73f262ac45c87cc
- https://git.kernel.org/stable/c/70bcb678561f0fb58f33270fc73f12f3be72b878
- https://git.kernel.org/stable/c/78a63fb2f7d5630d1c1f2859a20d4e4226863b41
- https://git.kernel.org/stable/c/8a3707653ab658e082ccd992e92594e01b09a3fc
- https://git.kernel.org/stable/c/aef897c9d2dd0d9339167fb82b62beff68d076cb
- https://git.kernel.org/stable/c/ced48f55bac73f0822eae90509e51b42b4f646c8
- https://git.kernel.org/stable/c/edfb1e094104a50f931553dc82ac59246569fd32
- https://git.kernel.org/stable/c/ff3a4487ead475e27b43280b8ee3d8464fe280e1
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate GPIO pin LUT table size before iterating [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/67461e0c15335894cc5d3b84cda823bf8cbdc886
- https://git.kernel.org/stable/c/7ca695b3122297b06a3ed605bbe1cd32c85d9f5a
- https://git.kernel.org/stable/c/86d2b20644b11d21fe52c596e6e922b4590a3e3f
- https://git.kernel.org/stable/c/9900f6954be779011e7c2cd42addd87baf028bc5
- https://git.kernel.org/stable/c/f2a4827e980ba07de4391fa84d9c39a12726bdd7
- https://git.kernel.org/stable/c/fb30a3890d62fd50a95aef684faf64a307592e42
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: use uninterruptible resv lock for plane updates virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/21ab64c77a30d56efc506c8fa2ad8959f8ce3d36
- https://git.kernel.org/stable/c/7930eee22cd3df61e85be8aa512032ab303b7167
- https://git.kernel.org/stable/c/8fadd01cf461fee5bb11506621339c548447e5c7
- https://git.kernel.org/stable/c/9af1b6e175c82daf4b423da339a722d8e67a735a
- https://git.kernel.org/stable/c/a2359a411b15f495d12cfda6a7db6855ebb7f90f
- https://git.kernel.org/stable/c/c86077d512ee980cc91322211d35dbcd3175f64c
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Reject MPA FPDU length underflow before signed receive math A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace: skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields do not agree on the start of an FPDU"), the correct framing-error class for this inconsistency.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0ce1bc9e46ecabe84772bb561e373c0d9876d6f2
- https://git.kernel.org/stable/c/1012896f4225e8f801ff3c1648023845b66dfb11
- https://git.kernel.org/stable/c/14553be882d9ce91749c9d64041de66e34ad8e70
- https://git.kernel.org/stable/c/33a8b5e971e294ec2a7b74211c545e09efd8e9ac
- https://git.kernel.org/stable/c/4a331582011d9e8089af8aa2a61ec6b4443bb245
- https://git.kernel.org/stable/c/683f7cfbf514193d63c0efa079f3352bde84c2e0
- https://git.kernel.org/stable/c/775b4dc9618a99a1fa48b57554041a5dc17e1336
- https://git.kernel.org/stable/c/c7c0c0f4379dedec12d24dbb9dded5d2db7fd9f2
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: scsi: isci: Fix use-after-free in device removal path The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() returns the IRQ handlers can still requeue the tasklet. The tasklet callback also re-enables interrupts after draining completions, so killing the tasklet before the source is quiesced leaves the same race open. Once wait_for_stop() returns, no further IRQ-driven scheduling can occur. Kill completion_tasklet there so teardown cannot race a queued tasklet running on a dead ihost. On remove or unload, the stale callback can otherwise dereference ihost and touch ihost->smu_registers after the host lifetime ends. A UML + KASAN analogue reproduced the failure class both with no tasklet_kill() and with tasklet_kill() placed before source quiesce, and stayed clean once the kill happened after quiescing the scheduling source. This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), but ISCI needs the kill after wait_for_stop().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1412995e10c74644b47f242aea6e4f3d4180e806
- https://git.kernel.org/stable/c/309c6058622d080fe8c2fab87c30da82d834d989
- https://git.kernel.org/stable/c/6d40f2f103bb30f52f3dbadbe2c3fdf274a9763c
- https://git.kernel.org/stable/c/a83d3e4daba40d49324cec1c51ed261e1ea48cf1
- https://git.kernel.org/stable/c/ab2266601a875982f2d2033f41e070a6d5e615e2
- https://git.kernel.org/stable/c/b52a8d52c3125ec9a93106ed816582368de34426
- https://git.kernel.org/stable/c/b9ff8631006233ba246828ac70409d2cb2da38d3
- https://git.kernel.org/stable/c/cb9e72c50e6c81a5903f27e0b397ce8525d7539b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Free private_irqs when init fails after allocation Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy() call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The kvm_vgic_vcpu_init() failure path immediately above it has the same shape and still needs the same cleanup. Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private IRQs allocated before a redistributor iodev registration failure are released before the failed vCPU is freed.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCRITICAL9.0
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range.
CVSS 3.xКРИТИЧЕСКАЯ 9.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0680f511926589206f81f57f76ce131d7741a316
- https://git.kernel.org/stable/c/1716b7fea2ead941a0dfac06c4504a3437cdf00d
- https://git.kernel.org/stable/c/8bcd15b690a390241179516af1b6ae49ebfd9d95
- https://git.kernel.org/stable/c/9ce754ed8e7ab4e3999767ce1505f85c449ccb07
- https://git.kernel.org/stable/c/b94538186a3eae3763b8f96dacd610920a865aa7
- https://git.kernel.org/stable/c/dab9f93251b2c86a033de6098d0c73afddd55d4a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix busy dentry used after unmounting Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry ref_cnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in generic_shutdown_super: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs] The detailed processs is: process A process B kworker fd = open(PATH) vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_fileinfo cfile->dentry = dget(dentry) // dentry->d_lockref.count = 2 close(fd) __fput cifs_close queue_delayed_work(deferredclose_wq, cfile->deferred) dput(dentry) // dentry->d_lockref.count = 1 smb2_deferred_work_close _cifsFileInfo_put list_del(&cifs_file->flist) umount cleanup_mnt deactivate_super cifs_kill_sb cifs_close_all_deferred_files_sb cifs_close_all_deferred_files // cannot find cfile, skip _cifsFileInfo_put kill_anon_super generic_shutdown_super shrink_dcache_for_umount umount_check WARN ! // dentry->d_lockref.count = 1 cifsFileInfo_put_final dput(cifs_file->dentry) // dentry->d_lockref.count = 0 Fix it by flushing 'deferredclose_wq' before calling kill_anon_super. Fetch a reproducer in https://bugzilla.kernel.org/show_bug.cgi?id=221548.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/5e7d9d0805e58fa3760894e73115b7a74024fd07
- https://git.kernel.org/stable/c/bdc349a87f1fb02c18c4071858a06542bfea783d
- https://git.kernel.org/stable/c/c68337442f03953237a94577beb468ab2662a851
- https://git.kernel.org/stable/c/c7364cea52531534676b9f7dbc0a477c11f4c050
- https://git.kernel.org/stable/c/e1ffa6cf662383f95816eed1b623429d82675e75
- https://git.kernel.org/stable/c/f2deaa2f409a4598eaa10f2a93a676c0632af248
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix UAF read of tail->len in unix_stream_data_wait() unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem. But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads: ``` static int socks[2]; void test_setup(void) { socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff)); } void test_thread1(void) { char dummy; recv(socks[0], &dummy, 1, MSG_PEEK); } void test_thread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUT_WR); } ``` when racing like this: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock) skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock) unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk) unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue) spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue) spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [frees the SKB] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen. Kuniyuki explained: > When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels before 6.5.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/26342087fac93b3932e6af61dc91ec029cb8a623
- https://git.kernel.org/stable/c/38bccb927d83d7d52e5b20015a172a0b6101d11e
- https://git.kernel.org/stable/c/5f162f95a95834f06a8ec6140889272ad12e842f
- https://git.kernel.org/stable/c/acdff9907478e82208475b1151700d0b71dcdc63
- https://git.kernel.org/stable/c/be309f8eae8b474a4a617eaae01324da996fc719
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: lsm: hold cred_guard_mutex for lsm_set_self_attr() Just as proc_pid_attr_write() already does before calling the LSM hook. This only matters for SELinux and AppArmor which check whether the process is being ptraced and if so, whether to allow the transition.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: rbd: eliminate a race in lock_dwork draining on unmap Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation. A more problematic example is maybe_kick_acquire(): if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) { dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); } It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race. When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action(). Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix use-after-free in VEPA multicast source pruning ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context. The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here. I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags): BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90) QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/3d931ac62411a7e43b85dba5fe45e1a4a91bd5cb
- https://git.kernel.org/stable/c/55b3e91d62b2f7a24109b2d7c9f4c66d2e3b1ec1
- https://git.kernel.org/stable/c/5d49b568c188dc77199d8d2b959c91da8cc27cf1
- https://git.kernel.org/stable/c/6ef30384a50a50e4a484cddf341bc27de31aa3de
- https://git.kernel.org/stable/c/a244395d8c563ed1bb26c3ef708db6aeeaa08084
- https://git.kernel.org/stable/c/add70e2682c0ad3be2a5810bcf1bc13963ba4df9
- https://git.kernel.org/stable/c/dfef79e09ed2f5df975c98547f97f5d7f8982a24
- https://git.kernel.org/stable/c/e8768bcbe5cd30c4ea36a22022c9ffaa66903693
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ipv4: raw: reject IP_HDRINCL packets with ihl < 5 raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length: iphlen = iph->ihl * 4; err = -EINVAL; if (iphlen > length) goto error_free; if (iphlen >= sizeof(*iph)) { /* fix up saddr, tot_len, id, csum, transport_header */ } It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic. An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path. Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to. Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it. Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl. Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev. Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1065b9efa4126df559b03a849c139ecfae92cd25
- https://git.kernel.org/stable/c/145e9afa5b905229b4788bb72c3255f5a5f77508
- https://git.kernel.org/stable/c/3c5411fa4944ed99af3d9d1de750ea8169b6dac9
- https://git.kernel.org/stable/c/5a564f737ec54d63e8ee221d3ff396d07586d464
- https://git.kernel.org/stable/c/7725cd3b471740fd23d25ed1da722c671fb2a5d3
- https://git.kernel.org/stable/c/915fab69823a14c170dbaa3b41978768e0fe62fc
- https://git.kernel.org/stable/c/bbe0be67de296176e7243c76e3d9f02f6ae9ff0b
- https://git.kernel.org/stable/c/bc20dbd48c26e743f7e0845020c11ed2ce8b15ee
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix UAF when peer resets connection during handshake vmci_transport_recv_connecting_server() returned err = 0 for a peer RST in its default switch arm: err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state = TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work(). One second later vsock_pending_work() observed is_pending=true and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object: BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it. The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch. Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1dd531e28f61edd286edc486ab068f135b5ae1eb
- https://git.kernel.org/stable/c/1e19f08552b90070ed18bafb1763c78297823af6
- https://git.kernel.org/stable/c/440447699c681e26ed58e9c309cad718270a18b4
- https://git.kernel.org/stable/c/47e63077605c6c2aa45b3df9847a8cdc1f1f6ef9
- https://git.kernel.org/stable/c/99e22ddf4edb63dc8382bc028af928056d3450cf
- https://git.kernel.org/stable/c/9fe74e42914c851d68069713b7b917a9c33faf26
- https://git.kernel.org/stable/c/cc27e989a5dfdfcfc1cca7c3be27a0c7532b46cb
- https://git.kernel.org/stable/c/ecda37f8faab3220da199335e42564cb7a9ad145
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: add NULL check for idev in ipv6_hop_ioam() Reported by Sashiko: The function ipv6_hop_ioam() accesses __in6_dev_get(skb->dev)->cnf.ioam6_enabled without validating the returned idev pointer. Because addrconf_ifdown() can concurrently clear dev->ip6_ptr via RCU, __in6_dev_get() can return NULL during interface teardown, which could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop option. Let's add a check and use SKB_DROP_REASON_IPV6DISABLED accordingly.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/09cbfd4b81ae90963dadb1de99b63b702e73290a
- https://git.kernel.org/stable/c/1dca7e491f070ac49b3d934f16ee953a53b37f38
- https://git.kernel.org/stable/c/902daac307eb7e1955ce05b071950f3cba88c963
- https://git.kernel.org/stable/c/abdd03229414b5a52943b65a60f34b84cea5ac59
- https://git.kernel.org/stable/c/c7e8971abd70e9d022f1c251ba2508f8dc7f2db8
- https://git.kernel.org/stable/c/cf75eb6617042c8cff6112daeed7791809fc9dd2
- https://git.kernel.org/stable/c/d4ea0dfd75011b78cebf3808f98ac4c4f51a6fb9
HIGH8.4
In the Linux kernel, the following vulnerability has been resolved: qed: fix double free in qed_cxt_tables_alloc() If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again. Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3. Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.
CVSS 3.xВЫСОКАЯ 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/06fa8e69019fd3c41a7b0ea8c5f509c3a33dc227
- https://git.kernel.org/stable/c/0e47fc1c9181ae029e0e35a865cbf2adcbae626c
- https://git.kernel.org/stable/c/2bccfb8476ca5f3548afbd623dc7a6980d4e77de
- https://git.kernel.org/stable/c/3904b993cc17ec5d7c5d3b57dbd0b775dafb9684
- https://git.kernel.org/stable/c/8cf5e4d2ca6b101d163c7423a426fb0aec34f7bb
- https://git.kernel.org/stable/c/9fe030719bd083b766602692ee96c8c985798e3c
- https://git.kernel.org/stable/c/a04c207f0801abdd23a169b5f902a9845059a65a
- https://git.kernel.org/stable/c/bdf678a273cadbccc347f331ae2e93ff4d14834c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: l2tp: use list_del_rcu in l2tp_session_unhash An unprivileged local user can pin a host CPU indefinitely in l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace suffices; on any host that has l2tp_core loaded the trigger is reachable from a standard `unshare -Urn` sandbox. l2tp_session_unhash() removes a session from tunnel->session_list with list_del_init(), but that list is walked by l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under rcu_read_lock_bh(). list_del_init() leaves the deleted entry's next/prev self-pointing; a reader that has loaded the entry and then advances pos->list.next reads &session->list, container_of()s back to the same session, and list_for_each_entry_rcu() never reaches the list head. The CPU stays in strcmp() inside the walker, with BH and preemption disabled, so RCU grace periods on the host stall behind it and the wedged thread cannot be killed (SIGKILL is delivered on syscall return). Use list_del_rcu() to match the existing list_add_rcu() in l2tp_session_register(); the deleted session remains visible to in-flight walkers with consistent next/prev pointers until kfree_rcu() in l2tp_session_free() releases it. tunnel->session_list has exactly one list_del_init() call site; the list_del_init (&session->clist) at l2tp_core.c:533 operates on the per-collision list, which is not walked under RCU. list_empty(&session->list) is not used anywhere in net/l2tp/ after the unhash point, so dropping the post-delete self-init is safe; the fix has no userspace-visible behavior change.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: net: ifb: report ethtool stats over num_tx_queues ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues. The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example: ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10 ifb_get_ethtool_stats() indexes past the tx_private allocation and copies adjacent slab data through ETHTOOL_GSTATS. Use dev->num_tx_queues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifb_q_private entry, which is the queue set IFB can actually populate. Reproduced under UML+KASAN at v7.1-rc2: BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifb_fill_stats_data+0x3c/0xae ifb_get_ethtool_stats+0xc0/0x129 __dev_ethtool+0x1ca5/0x363c dev_ethtool+0x123/0x1b3 dev_ioctl+0x56c/0x744 sock_do_ioctl+0x15f/0x1b2 sock_ioctl+0x4d5/0x50a sys_ioctl+0xd8b/0xde9 With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated tx_private entry.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- https://git.kernel.org/stable/c/16bd798cb6d8337d7c3eea1adc412f31b5181d5b
- https://git.kernel.org/stable/c/2638e1773904d7aa8f24c6e7fda2ed7d69df6fa4
- https://git.kernel.org/stable/c/301a554e458e2f5ec47f2c336a7cb03b877f9fd6
- https://git.kernel.org/stable/c/5db89c99566fc4728cc92e941d8e1975711e24b5
- https://git.kernel.org/stable/c/6afdb8113cb007f9332f59a9b7fd45731b8a9de5
- https://git.kernel.org/stable/c/f8a5a76b4a683043c6eff2a060bcaa17f9316ad5
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: keep RBUF EEE/PM disabled Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to DMA, so rx_packets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skb_release_data via bcmgenet_rx_poll on an LPI exit. Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUF_PM_EN is not publicly documented. This shows up more often now that phy_support_eee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes. Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/2040eb83f6ada148fb32dd98b943a498005d79f2
- https://git.kernel.org/stable/c/289499907399c5a9f2ed82cb34df49112bb8488f
- https://git.kernel.org/stable/c/3d4ef05266ab16d8ef7dd21658a557801eb78704
- https://git.kernel.org/stable/c/49bdf6bbb21b9c6e3f4d0c1910bf0ef98424be95
- https://git.kernel.org/stable/c/9a1730245e416d11ad5c0f2c100061d61cc43f60
- https://git.kernel.org/stable/c/a212fc08f5c48a16a94092bf0a9a8b7cf4483b11
- https://git.kernel.org/stable/c/b579f3a73da7a7e74213558f4cc3d865c30aaa78
- https://git.kernel.org/stable/c/f2782ddac82c70df313012da5f71f1f06b5553ca
HIGH7.3
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate Add Extended Advertising Data length MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload. A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read. Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data.
CVSS 3.xВЫСОКАЯ 7.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:LСсылки
- https://git.kernel.org/stable/c/0bc1a5a69f541859293d79db72bd7854ac48df51
- https://git.kernel.org/stable/c/0d5104390b445e7bd664ad583837e4c04d892c9d
- https://git.kernel.org/stable/c/14b01b9cba04e6ce82825f68fc4c4322fa4ffa43
- https://git.kernel.org/stable/c/a143ce77a5292f2c9285137433d879ce71d190a7
- https://git.kernel.org/stable/c/a6c75a3fad226ccbd8ef9110dee87c92c299f2ab
- https://git.kernel.org/stable/c/d3f7d17960ed50df3a6709c5158caff989c8c905
- https://git.kernel.org/stable/c/f1febe93ef075314615f970a87681d9ab86691d1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure() from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the size and source-pointer arguments to l2cap_send_cmd(): - struct { - struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1); ... l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu); After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous union pdu_u plus a local pointer "pdu" pointing at it. Therefore: - sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]). - &pdu is the address of the local pointer's stack storage, not the address of the request payload. l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet body therefore contains 8 bytes copied from the kernel stack starting at &pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel stack address to the paired Bluetooth peer. The intended (mtu, mps, scid) fields are not transmitted at all, so the peer rejects the request as malformed and the L2CAP_ECRED_RECONFIGURE feature itself has been broken for the local-side initiator since the introducing commit landed. The sibling site l2cap_ecred_conn_req() in the same commit was converted correctly (sizeof(*pdu) + len, pdu); only this site was missed. Restore the original semantics: pass the full flex-struct size via struct_size(pdu, scid, 1) and the pdu pointer (the struct address) as the source. Validated on a stock 7.0-based host kernel via the real call path: setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTED L2CAP_MODE_EXT_FLOWCTL socket emits an L2CAP_ECRED_RECONFIGURE_REQ whose body is 8 bytes (the on-stack pdu local's value) rather than the expected 6. Three captures from fresh socket / fresh hciemu peer on the same host -- low bytes vary per call, high 0xffff confirms a kernel virtual address (KASLR-randomised stack slot, not a fixed string): RECONF_REQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff RECONF_REQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff RECONF_REQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff After this patch the body is 6 bytes carrying the expected little-endian (mtu, mps, scid).
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: drop ISO_END frames received without prior ISO_START ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing ISO_START by checking conn->rx_len before touching conn->rx_skb, but ISO_END does not. If a peer sends an ISO_END as the first packet on a fresh ISO connection, conn->rx_skb is still NULL and conn->rx_len is zero, so skb_put(conn->rx_skb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this. Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment is logged and dropped instead of crashing the host.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1c3d1e1696b72579b970e17999c503a14535205b
- https://git.kernel.org/stable/c/39f4a82e80c8f5ed2d6952d73fbafc895721a728
- https://git.kernel.org/stable/c/3af41ee7ebecb0d5c8a504861f6cfad31345310f
- https://git.kernel.org/stable/c/61f2410a96dee808029e2ae4d6ef2dd635f3477f
- https://git.kernel.org/stable/c/84c24fb151fc1179355296d7ff29129ac7c42129
- https://git.kernel.org/stable/c/e3a799881c12d27596232636a607e2e3fa448d63
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: refresh hdr pointer before ioam6_event() Reported by Sashiko: In ipv6_hop_ioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skb_ensure_writable(), which might reallocate the buffer: if (skb_ensure_writable(skb, optoff + 2 + hdr->opt_len)) goto drop; /* Trace pointer may have changed */ trace = (struct ioam6_trace_hdr *)(skb_network_header(skb) + optoff + sizeof(*hdr)); ioam6_fill_trace_data(skb, ns, trace, true); ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb->dev), GFP_ATOMIC, (void *)trace, hdr->opt_len - 2); If the skb is cloned or lacks sufficient linear headroom, skb_ensure_writable() will invoke pskb_expand_head(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skb_ensure_writable(), it fails to recalculate the hdr pointer. This patch fixes the above by recalculating the hdr pointer before passing hdr->opt_len to ioam6_event(), so that we avoid any UaF.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access at reading cache find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/34d0d492a2812b9289af14bca3573a89275965b2
- https://git.kernel.org/stable/c/61c5017c64e2ac9e10b70b14b17a079dbc0a805f
- https://git.kernel.org/stable/c/7b6f8c8eb93f02a74b1de8e521c0952af10d1f43
- https://git.kernel.org/stable/c/7b7d6572145c1dab2dd9bfb550b188e5f0ff3c3f
- https://git.kernel.org/stable/c/7d107239935793995bdc6cf29bb99e180bde4c28
- https://git.kernel.org/stable/c/8778386e4387b28f2bf8425d7ffc667c6294457f
- https://git.kernel.org/stable/c/e060e21fe9cca1e5eafd8a1c597026577771e8d9
- https://git.kernel.org/stable/c/ffa29cea7bf9a4ef2ea8084967f142e0301ac670
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Don't setup bogus iov_iter for silencing At transition to the iov_iter for PCM data transfer, we blindly applied the iov_iter setup also for silencing (i.e. data = NULL), and it leads to a calculation of bogus iov_iter. Fortunately this didn't cause troubles on most of architectures but it goes wrong on RISC-V now, causing a NULL dereference. Handle the NULL data case to treat the silencing in interleaved_copy() for addressing the bug above. noninterleaved_copy() has already the NULL data handling, so it doesn't need changes.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/41a766c647294842c9b17672449f8e011048cba9
- https://git.kernel.org/stable/c/c9f6768515818d71bdfc20119a81f3332c53b9c6
- https://git.kernel.org/stable/c/ce836587e594af39ff048d9b29dee0f5f10692c9
- https://git.kernel.org/stable/c/e4d3386b74fba8e01280484b67ee481ece00201e
- https://git.kernel.org/stable/c/feff0251386aa6bb180a0a1cf7c1f91ba868113d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2C_SMBUS_BLOCK_MAX = 32): memcpy(values, &data.block[1], data.block[0]); If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call if (ret != 4) return -EIO; check has a chance to reject the response. Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0dbf64c502443c08c2e28a77ecbfcc5479d93228
- https://git.kernel.org/stable/c/2b7a698d5093b548c464828d984f05ced5f3fd2a
- https://git.kernel.org/stable/c/33251abb9c9dd62943be76f0427c5527ee39188f
- https://git.kernel.org/stable/c/6ed16a40b162e9d87d9ac8bed4d7f0e3e807700e
- https://git.kernel.org/stable/c/7f705e581ef3e6bb308a121a89adf5237d968204
- https://git.kernel.org/stable/c/ba09f4baa5bd96c5d26c942defa546a72dbbe5bf
- https://git.kernel.org/stable/c/ca560f7566df7e2826c2999e959e6b94eb938f76
- https://git.kernel.org/stable/c/eee213daa1e1b402eb631bcd1b8c5aa340a6b081
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked() Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes. There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked().
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/13fb413ae22a37c69341918a6d651d19a9b0b9b7
- https://git.kernel.org/stable/c/4d8690dace005a38e6dbde9ecce2da3ad85c7c41
- https://git.kernel.org/stable/c/7df1df6f40c0720d30206aa35c0343b962350e0d
- https://git.kernel.org/stable/c/bf4ebdb19ff9b3cdf992b50715fe61633327416a
- https://git.kernel.org/stable/c/e374f4e496fef8168784f93a4477d67be34485fd
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: smb: client: require net admin for CIFS SWN netlink CIFS_GENL_CMD_SWN_NOTIFY is the userspace witness-notify command. The intended sender is the cifs.witness helper, but the generic-netlink operation currently has no capability flag, so any local process can send RESOURCE_CHANGE or CLIENT_MOVE notifications to the in-kernel witness handler. The same family exposes CIFS_GENL_MCGRP_SWN without multicast-group capability flags. Register messages sent to that group include the witness registration id and, for NTLM-authenticated mounts, the username, domain, and password attributes copied from the CIFS session. An unprivileged local process should not be able to join that group and receive those messages. Require CAP_NET_ADMIN for incoming SWN_NOTIFY commands with GENL_ADMIN_PERM, and require CAP_NET_ADMIN over the network namespace for joining the SWN multicast group with GENL_MCAST_CAP_NET_ADMIN. The cifs.witness service runs with the privileges needed for both operations.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/969bc6370334a5b4720c5470783295d6484bbc95
- https://git.kernel.org/stable/c/9919021a3b7974ae66a5f9915e3a48c10cfd409b
- https://git.kernel.org/stable/c/9cf7eb8919344932f909b2fac76296f7656fda8d
- https://git.kernel.org/stable/c/a3238b09c58f323e40743ce174cd0ab81b5c09ed
- https://git.kernel.org/stable/c/a8d17d22db591099519a89f14dd24810daba74c3
- https://git.kernel.org/stable/c/c2397b93fbb6f44a788fff30f99be2c20cc5e50f
- https://git.kernel.org/stable/c/d1ebfce2c1d161186a82e77590bf7da2ea1bce91
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: test_kprobes: clear kprobes between test runs Running the kprobes sanity tests twice makes all tests fail and eventually crashes the kernel. [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # Totals: pass:5 fail:0 skip:0 total:5 ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64 Expected 0 == register_kprobe(&kp), but register_kprobe(&kp) == -22 (0xffffffffffffffea) ... Unable to handle kernel paging request ... The testsuite defines several kprobes and kretprobes as static variables that are preserved across test runs. After register_kprobe and unregister_kprobe, a kprobe contains some leftover data that must be cleared before the kprobe can be registered again. The tests are setting symbol_name to define the probe location. Address and flags must be cleared. The existing code clears some of the probes between subsequent tests, but not between two test runs. The leftover data from a previous test run makes the registrations fail in the next run. Move the cleanups for all kprobes into kprobes_test_init, this function is called before each single test (including the first test of a test run).
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/08d355936fcf70c81c94f9fe7310450b65c53399
- https://git.kernel.org/stable/c/1c24cf1fd67f6702c719ab73499392cb7af956ae
- https://git.kernel.org/stable/c/96515819d79f356f40da5540968d838ea570fab9
- https://git.kernel.org/stable/c/accc0004c501a9918313142282b094d408af06fb
- https://git.kernel.org/stable/c/ef5581bb30efb939cc2bf093475c6cc85258e5cd
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file()
The trace event btrfs_sync_file() is called in an atomic context (all trace
events are) and its call to dput(), which is needed due to the call to
dget_parent(), can sleep, triggering a kernel splat.
This can be reproduced by enabling the trace event and running btrfs/056
from fstests for example. The splat shown in dmesg is the following:
[53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970
[53.947] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 32773, name: xfs_io
[53.988] preempt_count: 2, expected: 0
[53.967] RCU nest depth: 0, expected: 0
[53.943] Preemption disabled at:
[53.944] [<0000000000000000>] 0x0
[54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfs_io Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full)
[54.070] Tainted: [W]=WARN
[54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[54.072] Call Trace:
[54.074]
[54.076] dump_stack_lvl+0x56/0x80
[54.079] __might_resched.cold+0xd6/0x10f
[54.072] dput.part.0+0x24/0x110
[54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs]
[54.089] btrfs_sync_file+0x1ed/0x530 [btrfs]
[54.087] ? __handle_mm_fault+0x8ae/0xed0
[54.089] btrfs_do_write_iter+0x172/0x210 [btrfs]
[54.091] vfs_write+0x21f/0x450
[54.094] __x64_sys_pwrite64+0x8d/0xc0
[54.096] ? do_user_addr_fault+0x20c/0x670
[54.099] do_syscall_64+0x60/0xf20
[54.092] ? clear_bhb_loop+0x60/0xb0
[54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e
So stop using dget_parent() and dput() and access the parent dentry
directly as dentry->d_parent. This is also what ext4 is doing in
its equivalent trace event ext4_sync_file_enter().
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a96d9a85cd2240481297156b9bb72e10b7a8036
- https://git.kernel.org/stable/c/12a0487945c09760a5968d9333383014ea294117
- https://git.kernel.org/stable/c/26b2290baaf6da6add0f782a100766e686a33f4f
- https://git.kernel.org/stable/c/4361954f0e158af0530caa1e57f12b531be4658f
- https://git.kernel.org/stable/c/6279992c9ba2774901c9d4dd4a481162e2534714
- https://git.kernel.org/stable/c/c32a7e0e3c73c1c0768556a56bd78de9f7b83780
- https://git.kernel.org/stable/c/c73370c677646e86fc4b1780fb07027bdf847375
- https://git.kernel.org/stable/c/d78b0a80eac36879ef5478707135c446920e134b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ARM: integrator: Fix early initialization Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible which in turn calls of_syscon_register. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows. Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at __kmalloc_cache_noprof+0xec/0x39c LR is at __kmalloc_cache_noprof+0x34/0x39c ... Call trace: __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310 of_syscon_register from device_node_get_regmap+0xa4/0xb0 device_node_get_regmap from intcp_init_early+0xc/0x40 intcp_init_early from start_kernel+0x60/0x688 start_kernel from 0x0 The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to syscon_regmap_lookup_by_compatible returns -ENOMEM, and sched_clock_register is never called. Fix the problem by moving the early initialization code into the standard machine initialization code.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/22c738fb51f2d8b23ddff5cc0ccb2dd685bb39d3
- https://git.kernel.org/stable/c/33ad014abec90f37dade0e00560f28864187e21a
- https://git.kernel.org/stable/c/508b1193d63b5e073a3fe103eeb785fcba2d368c
- https://git.kernel.org/stable/c/58a112b0973f6cd6bcb8c503d1ff88be411ed0f0
- https://git.kernel.org/stable/c/6624854554c4c2bdfed3559e5c11bb03b16e7bd1
- https://git.kernel.org/stable/c/812103fb6da904bd03d62cf6a9826e537318ceed
- https://git.kernel.org/stable/c/90d77b30a666049ad24df463f52e5d529c44e8cd
- https://git.kernel.org/stable/c/e984dc22e2c24dc34d6728e338c82b1ce7862753
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Check for NULL FF-A ID table while driver registration The bus match callback assumes that every FF-A driver provides an id_table and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0a5e695095c557d2380131b613dea4e8d90371be
- https://git.kernel.org/stable/c/198f6c86d508ed562f07dc00276cac6dbb5dd3bf
- https://git.kernel.org/stable/c/34f59211984f66788390e7469f3e99d3796db4a8
- https://git.kernel.org/stable/c/820245d86ce58898fb48b4fefc77d0cafc02801d
- https://git.kernel.org/stable/c/adfff93d08a2e12ecf2a1eba272d18bc749f13c0
- https://git.kernel.org/stable/c/bc499d1acddbb75b5b4bce05f5296dd8ef9611fd
- https://git.kernel.org/stable/c/f98f131256beaddd51ad468e95d90d857fef12bf
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: sprd: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0cdea166c1a07c200caf9d0b722224fca43b23ae
- https://git.kernel.org/stable/c/3d67fffb74267772d461c02c67f1eff893ad547d
- https://git.kernel.org/stable/c/450c319dd04d0eeff4184889768f7ada826a2e35
- https://git.kernel.org/stable/c/a8f233fb0c7be29b97cd249f64120bf35ce72805
- https://git.kernel.org/stable/c/b6f1acf4e57ccf708cdc0cb70f5bb5b65162963b
- https://git.kernel.org/stable/c/be409d2bbe9ca7da7b05cc7dde7499bc481f0766
- https://git.kernel.org/stable/c/be74e276111f3c23b8e040c8c5e308f67a573add
- https://git.kernel.org/stable/c/c33b4496e95d04722055446c0a31213639438536
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: ep93xx: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: qup: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0bb3bd442f0bdad3932739a61dd6c580c9c1955e
- https://git.kernel.org/stable/c/45760b72e84c1a1498f1a8a9047184c85299da20
- https://git.kernel.org/stable/c/4bb4764f2c51f03f657a28029eb0595d8223aab5
- https://git.kernel.org/stable/c/4f4051e9d644c371c50de4a042b85bba6727d5c3
- https://git.kernel.org/stable/c/8f9b61d255b1e989b8913b06c8ebe0aba5e1b238
- https://git.kernel.org/stable/c/9e673affb92c29d9ba879bf4ea81c5e840166b56
- https://git.kernel.org/stable/c/a7e8f3efd50a165ba0189f6dc57f7e51a7d149db
- https://git.kernel.org/stable/c/d577c55d189e7ae150973058d13e299b6855633f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tracing: Do not call map->ops->elt_free() if elt_alloc() fails In paths where tracing_map_elt_alloc() failed to allocate objects, the map->ops->elt_alloc() call was never successful. In this case, map->ops->elt_free() should not be called.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1a150947f8480262a46c860f1acb9c6597ca7097
- https://git.kernel.org/stable/c/49332e49ad5b20262cc719b03d4123b9362de701
- https://git.kernel.org/stable/c/798183376d9d3e278a270ea0e75a5769c8f145d9
- https://git.kernel.org/stable/c/8f0f5c4fb9df0e19a341e0c6ed8dc4fda9124f03
- https://git.kernel.org/stable/c/b427e9f6d81c9341cba23ef92f860f99f830d91d
- https://git.kernel.org/stable/c/b559a218eece132de0c58d444877b5627cbee524
- https://git.kernel.org/stable/c/b6723339736320b2e1784258ad4490cec7aac11a
- https://git.kernel.org/stable/c/f383cff9fb382139980bac1bcd3f3f5d59f68435
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: advance loop vars in cfg80211_merge_profile() cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem) but never advances mbssid_elem or sub_elem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same next_mbssid; and the same next_sub bytes are memcpy()'d into merged_ie at a growing offset until the buffer fills. Advance both mbssid_elem and sub_elem to the just-consumed continuation so the next call to cfg80211_get_profile_continuation() searches for a further continuation beyond it (or returns NULL when none exists). A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211_merge_profile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1343a480f84b80c1249133a90ef87f8751d65cbb
- https://git.kernel.org/stable/c/1ced0f5a851f9cae274545a42a06c459b7fd8881
- https://git.kernel.org/stable/c/5817e1e5205498a5df66eba2b34e817f4210fd0f
- https://git.kernel.org/stable/c/67915715fd3874057457363c87c63e18829527df
- https://git.kernel.org/stable/c/6cfae4914439878b8acb35c7e3b40096eeb2ad9c
- https://git.kernel.org/stable/c/7666dbb1bacc4ba522b96740cba7283d243d16e1
- https://git.kernel.org/stable/c/c0bc4c8bd556cbe036a5b9ed333c0aab9aadfcb8
- https://git.kernel.org/stable/c/cedbb608494ba1e7a5c6c56b7f1d3fd470094f28
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: phonet/pep: disable BH around forwarded sk_receive_skb() The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case release_sock() -> __release_sock() drops the slock with spin_unlock_bh() and then calls sk->sk_backlog_rcv() with bottom halves enabled. Typical sk_backlog_rcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pep_do_rcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different *child* socket via sk_receive_skb(). That helper takes the child slock with bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path): process context softirq context --------------- --------------- release_sock(listener) __netif_receive_skb() __release_sock() phonet_rcv() spin_unlock_bh() __sk_receive_skb(listener) [BH now ENABLED] [BH already disabled] sk_backlog_rcv: sk_backlog_rcv: pep_do_rcv() pep_do_rcv() sk_receive_skb(child) sk_receive_skb(child) bh_lock_sock_nested(child) bh_lock_sock_nested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path: WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900 __sk_receive_skb net/core/sock.c:563 sk_receive_skb include/net/sock.h:2022 [inline] pep_do_rcv net/phonet/pep.c:675 sk_backlog_rcv include/net/sock.h:1190 __release_sock net/core/sock.c:3216 release_sock net/core/sock.c:3815 pep_sock_accept net/phonet/pep.c:879 Wrap the forwarded sk_receive_skb() in local_bh_disable() / local_bh_enable() so the child slock is always acquired with BH off. local_bh_disable() nests safely on the softirq path. Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer: https://pastebin.com/A3t8xzCR
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/02c04df84de709060f63e1d52ec67488c4f6f212
- https://git.kernel.org/stable/c/8420aa4900417797323dd567ba9d1512280c2dc3
- https://git.kernel.org/stable/c/84bc87beb4cd77670939b446326788e4c9b3db37
- https://git.kernel.org/stable/c/a3fc8f2dacd1c37325977fc1fbbf3d52141df99e
- https://git.kernel.org/stable/c/b2606c302d7f2b4ee48da05e32ed60aed1b0cd53
- https://git.kernel.org/stable/c/bd795f106b3889fb0706c6e4831c4b27e2b5666b
- https://git.kernel.org/stable/c/dbc81608e3a653dea6cf403f20cae35468b8ab9c
- https://git.kernel.org/stable/c/f08c45076e4fd8b0adbc5eb186d6e6a3e7350d7b
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: Fix UAF read of dev->name bnep_add_connection() needs to keep holding the bnep_session_sem while reading dev->name (just like bnep_get_connlist() does); otherwise the bnep_session() thread can concurrently free the net_device, which can for example be triggered by a concurrent bnep_del_connection(). (This UAF is fairly uninteresting from a security perspective; calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/4907596f25b1720fa948371ac5f6c1f8da10a5bc
- https://git.kernel.org/stable/c/5506aec795135cdd4cbf4e845929155663b25055
- https://git.kernel.org/stable/c/59e932ded949fa6f0340bf7c6d7818f962fa4fd2
- https://git.kernel.org/stable/c/915a92182e2cda9cd7d2479020a44c6eda986f7c
- https://git.kernel.org/stable/c/a75bbcb10cb21acc169b785e9804f57d97873a9c
- https://git.kernel.org/stable/c/b21805258d7e926adfd455fc820a447b90da3b82
- https://git.kernel.org/stable/c/e7578529b97e5d4e439cf8f3e637c2303015338f
- https://git.kernel.org/stable/c/fe69f634b076ae3ca81c5a5b845d9bba527036f7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix potential memory leaks in ipc_imem_init() The memory allocated in ipc_protocol_init() is not freed on the error paths that follow in ipc_imem_init(). Fix that by calling the corresponding release function ipc_protocol_deinit() in the error path.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/583fd5a8fc797c8ecf2e1a7b923740c5e5734e85
- https://git.kernel.org/stable/c/6f63a60580ebdd9a1f22f89a84814d1fefe16b1c
- https://git.kernel.org/stable/c/8f764a7810a9f114313c439d25b11f4417c6e0dd
- https://git.kernel.org/stable/c/ba6d8643019c33428f7c0658863e80e0b04a70f4
- https://git.kernel.org/stable/c/c5d93b2c40355e999715262a824965aac025a427
- https://git.kernel.org/stable/c/f1a4d57847813fae42fbb7eb35f2dd48b9cff8a9
- https://git.kernel.org/stable/c/ffb6dbb49c96be82f07c7b112e3ebc3e6fdd8dd5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm/memory_hotplug: fix memory block reference leak on remove Patch series "mm: Fix memory block leaks and locking", v2. This series fixes two memory block device reference leaks and one locking issue around the per-memory_block hwpoison counter. This patch (of 2): remove_memory_blocks_and_altmaps() looks up each memory block with find_memory_block(), which acquires a reference to the memory block device. That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: fix memory block reference leak in poison accounting memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block via find_memory_block_by_id(), which acquires a reference to the memory block device. Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nr_hwpoison.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/03a2cc1756a0570f887d624cd6c535ea0cbd4951
- https://git.kernel.org/stable/c/24840b3139d7415144b81e4f9f4c44670d15bed9
- https://git.kernel.org/stable/c/686b4283f82cd630fafd7ca9b03dfc080b3ec8fa
- https://git.kernel.org/stable/c/8502e2c2d0633f99d94d22ae8dabc10caae1fc2a
- https://git.kernel.org/stable/c/ce60d9452a0f2effa72fd20ea270c59ca691d455
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: efi: Allocate runtime workqueue before ACPI init Since commit 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers") ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware. Rafael reports that such PRM accesses may occur before efisubsys_init() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpi_init() [which triggers the early PRM accesses] executes as a subsys_initcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpi_init() is not an option. So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsys_initcall() level.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/13c6da02e767152c9ac4330962247a5e47011035
- https://git.kernel.org/stable/c/29cd94e678fcb3c4fd0f359deeac6d61334323fc
- https://git.kernel.org/stable/c/6996e954ae830f5b793ba6cf449885ca519dbdd2
- https://git.kernel.org/stable/c/c32a1fbe0f9a48453a552bb315cc4f1e7a74084e
- https://git.kernel.org/stable/c/e871549f7894ad4114b3dd53f241aa25a268ba8b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break() damon_sysfs_memcg_path_to_id() breaks mem_cgroup_iter() loop without calling mem_cgroup_iter_break(). This leaks the cgroup reference. Fix the issue by calling mem_cgroup_iter_break() before the break. The issue was discovered [1] by Sashiko.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/082351f9d40007414ad6af062b3a26fa02fd4b5f
- https://git.kernel.org/stable/c/1bd31386ec3b9ccec10c04429948a306ec5897c0
- https://git.kernel.org/stable/c/302e02f9ba49f81418ec2a749ae6f5cac1d424e9
- https://git.kernel.org/stable/c/30a361be33f3793b9ecbd10ab7be6d0564819b79
- https://git.kernel.org/stable/c/d4e7b5c4cc353f154d5ab8bb2e1ce7714d77a6e9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: sysfs: don't remove existing directory on update failure When sysfs_update_group() is called for a named group and create_files() fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on the group directory. In the update path, kn was obtained via kernfs_find_and_get() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create. Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by remove_files() inside create_files(), but can be repopulated by a retry.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/14f2c14ae86c4af17a0a9f8ab46dacf2d5fd1d8a
- https://git.kernel.org/stable/c/237557b8a81ab948e8332f7c0058e758f081c0a3
- https://git.kernel.org/stable/c/31527d80234caf83dc96ad478645e57df9de4472
- https://git.kernel.org/stable/c/48fa96538bd2868034d33429e4565fda384d0736
- https://git.kernel.org/stable/c/57b285e0368290aa55f79ba11419b96d0ebdb418
- https://git.kernel.org/stable/c/708f6926f61f71e09b5e9fd668b9882ccd46e69f
- https://git.kernel.org/stable/c/c5e125c828b701afaf7493b42a14aa89362ff36d
- https://git.kernel.org/stable/c/ccadd32cc1263802a5969c9efe0e96225450428c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()
A kernel panic is observed when handling machine check exceptions from
real mode.
BUG: Unable to handle kernel data access on read at 0xc00000006be21300
Oops: Kernel access of bad area, sig: 11 [#1]
MSR: 8000000000001003 CR: 88222248 XER: 00000005
CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0
NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70
LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150
Call Trace:
[c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150
[c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0
The crash occurs because arch_irq_work_raise() calls preempt_disable()
from machine check exception (MCE) handlers running in real mode. In
this context, accessing the preempt_count can fault, leading to the panic.
The preempt_disable()/preempt_enable() pair in arch_irq_work_raise()
was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix
oops due to perf_event_do_pending call") to avoid races while raising
irq work from exception context.
Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when
queueing work on the local CPU") added preemption protection in
irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per
cpu atomics instead of regular atomics") added equivalent
protection in irq_work_queue_on() before reaching arch_irq_work_raise():
irq_work_queue() / irq_work_queue_on()
-> preempt_disable()
-> __irq_work_queue_local()
-> irq_work_raise()
-> arch_irq_work_raise()
As a result, callers other than mce_irq_work_raise() already execute
with preemption disabled, making the additional
preempt_disable()/preempt_enable() pair in arch_irq_work_raise()
redundant.
The arch_irq_work_raise() function executes in NMI context when called
from MCE handler. Hence we will not be preempted or scheduled out since
we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove
the preempt_disable()/preempt_enable() calls from here.
Remove it to avoid accessing preempt_count from real mode context.
[Maddy: Fixed the commit title]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/31467b23823ffec1f6fff407f8e3ca9af8b7491a
- https://git.kernel.org/stable/c/51860e423592893cd7bfa7287d99a3aff4dc3a9d
- https://git.kernel.org/stable/c/6dcd072a5ae3aed336e4a67a7d4cc5205b240065
- https://git.kernel.org/stable/c/72d8d1c36452a4d3ee134b1da48de7518c1329f9
- https://git.kernel.org/stable/c/8079acc5ee5235a627e4586d4f42082a9000ea64
- https://git.kernel.org/stable/c/a09d07ac45e283c9861a9ceea06f56d0ba851d22
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix overrun check in netfs_extract_user_iter() Fix netfs_extract_user_iter() so that if iov_iter_extract_pages() overfills pages[], then those pages don't get included in the iterator constructed at the end of the function. If there was an overfill, memory corruption has already happened.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/00efe58bbdcc93272d579ca24bfc912563f4a204
- https://git.kernel.org/stable/c/0ef37eef83fad3542ee06db2940433ae1a92b39d
- https://git.kernel.org/stable/c/96cc3beb2390ba9f9c128c5733c0ccfe450dd4f9
- https://git.kernel.org/stable/c/afeb32d9bf9aaeea51d0f723a19f14afb73bd94d
- https://git.kernel.org/stable/c/f48b9157f0f611fa436c360648603d5ded719b12
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix report_work leak on backbone_gw purge batadv_bla_purge_backbone_gw() removes stale backbone gateway entries, but fails to properly handle their associated report_work: - If report_work is running, the purge must wait for it to finish before freeing the backbone_gw, otherwise the worker may access freed memory (e.g. bat_priv). - If report_work is pending, the purge must cancel it and release the reference held for that pending work item. The previous implementation called hlist_for_each_entry_safe() inside a spin_lock_bh() section, but cancel_work_sync() may sleep and therefore cannot be called from within a spinlock-protected region. Restructure the loop to handle one entry per spinlock critical section: acquire the lock, find the next entry to purge, remove it from the hash list, then release the lock before calling cancel_work_sync() and dropping the hash_entry reference. Repeat until no more entries require purging.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/0459430add32ea41f3e2ef9351610e6d33627a6b
- https://git.kernel.org/stable/c/3423a45e5c3d3c5129f88143a9a969787d7d5a0a
- https://git.kernel.org/stable/c/48663158222b3b7f6ee6791a67d512ede7fc94bb
- https://git.kernel.org/stable/c/95a7034661274cf5985708bd2f6d86ee46f88fa9
- https://git.kernel.org/stable/c/c6de1a5a9c406e30b91f1515a6ce05cc84023baa
- https://git.kernel.org/stable/c/ce2c0ee4d76d5ee4b391fe0e31334361e25030ec
- https://git.kernel.org/stable/c/eeddd7bab3d59c1e98642a204141f8c5d6194707
- https://git.kernel.org/stable/c/f1303adb1e59582f76c22798a2e2e150e054a9e7
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/16a5fa57565afb6bf37e18129921c270c93d8e2b
- https://git.kernel.org/stable/c/1c8c6e912f2945b2a3e669afca6b52174b88e86e
- https://git.kernel.org/stable/c/1ecde19bfce6535bffddad1139ff466b6d401b8e
- https://git.kernel.org/stable/c/3265f3ed373fb8048be713aadcdf702579a0e53d
- https://git.kernel.org/stable/c/6c92f6d9600efa3ef0d9e560a2b52776d9803c29
- https://git.kernel.org/stable/c/90c398e822ca76e40548df0c061dd4f93ea92d71
- https://git.kernel.org/stable/c/d6590e3f766e3111dd1beaf88b9384d117acfa6b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: device property: set fwnode->secondary to NULL in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/215c90ee656114f5e8c32408228d97082f8e0eef
- https://git.kernel.org/stable/c/34bf74b1fd2e4a44e27821a329204caf09df2976
- https://git.kernel.org/stable/c/371f53925a6714d0aa35f1aefdffc3e8cd62f480
- https://git.kernel.org/stable/c/3f1024deeab3b5443c29b3de4fe475e87309b8fa
- https://git.kernel.org/stable/c/508fd8ab158abd04b7f7d0f707cd6d6c405df4ea
- https://git.kernel.org/stable/c/f0e211d6539fae800217c10797993b7592d6ab01
- https://git.kernel.org/stable/c/f59e686c778cb41b8f7aa8fab2afd6a01afb3d47
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: spi: ti-qspi: fix use-after-free after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/178b9b570c0f75fa7e691490520328b20d19138e
- https://git.kernel.org/stable/c/1cd927002120678bd5d23c760246639caa53040e
- https://git.kernel.org/stable/c/3bbbe7ae3fdada0df4157c1ffe989f92dfa8dcd6
- https://git.kernel.org/stable/c/9c6f306a8140962c7284197db54b96fdb5f468d6
- https://git.kernel.org/stable/c/d6f422b122922d1abee907d673bcc990e5f3672d
- https://git.kernel.org/stable/c/d7a076fb596c7b408ed6df74793a597990a6d860
- https://git.kernel.org/stable/c/ea6ec3343e05f7937a53eb6d7617b3abdb4abc19
- https://git.kernel.org/stable/c/f2dc841d7dc9063fe9b47ced869b1271e55052ae
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: consume only present negotiated TTLM maps ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements against the number of link-map entries indicated by link_map_presence. ieee80211_parse_neg_ttlm() must consume the same layout. The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element. The bad bytes land in neg_ttlm->{up,down}link[tid] but are gated by valid_links before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state. Advance the cursor only when the current TID has a map present.
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: CGX: add bounds check to cgx_speed_mbps index cgx_speed_mbps has 13 elements but RESP_LINKSTAT_SPEED can yield values 0-15. If it returns a value >= 13, this causes an out-of-bounds array access. Add a bounds check and default to speed 0 if the index is out of range.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/2c3d26b4a62454945ba9ef3af3174d3e40e7afef
- https://git.kernel.org/stable/c/47a4cf2229be379cf88f92e32e1240337cd6273f
- https://git.kernel.org/stable/c/8201bf45cc7c1c1a09290c4db8ab1e19801f8fec
- https://git.kernel.org/stable/c/93d3dc81098cd60fb74d434ba7985ddfd9de5acb
- https://git.kernel.org/stable/c/94071141f00bc414e8f8f7f5db3b5143d535299f
- https://git.kernel.org/stable/c/985b5e38ac4f4d5ff03c8bfd8484353b440a1579
- https://git.kernel.org/stable/c/c0bf0a4f3f1f5f57aa83e1400ba4f56f0abfd542
- https://git.kernel.org/stable/c/e043017ac429caee73bd30c5a725659f1a3a4568
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF. Move put_task_struct() past scx_error().
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: don't dump registers past the mapped region On DSI 6G platforms the IO address space is internally adjusted by io_offset. Later this adjusted address might be used for memory dumping. However the size that is used for memory dumping isn't adjusted to account for the io_offset, leading to the potential access to the unmapped region. Lower ctrl_size by the io_offset value to prevent access past the mapped area. msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P) msm_dsi_host_snapshot+0x4c/0x78 [msm] msm_dsi_snapshot+0x28/0x50 [msm] msm_disp_snapshot_capture_state+0x74/0x140 [msm] msm_disp_snapshot_state_sync+0x60/0x90 [msm] _msm_disp_snapshot_work+0x30/0x90 [msm] kthread_worker_fn+0xdc/0x460 kthread+0x120/0x140 Patchwork: https://patchwork.freedesktop.org/patch/721747/
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/567b5e976e2e15280d78c9ef2add1954a0bbb5b1
- https://git.kernel.org/stable/c/5b49a46baa853b26dbefa65c6c75dd9ff69f63d4
- https://git.kernel.org/stable/c/5e2c196c3430fb94225c4102b1028d0146544761
- https://git.kernel.org/stable/c/9f8274749d9010a1a72f97e547b7eb9ebb82345b
- https://git.kernel.org/stable/c/a184aec790135938b0fadb415e55accd1f8685a0
- https://git.kernel.org/stable/c/ab871d5882953e5574ae2bc47bec88c2e3d22663
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved:
block: recompute nr_integrity_segments in blk_insert_cloned_request
blk_insert_cloned_request() already recomputes nr_phys_segments
against the bottom queue, because "the queue settings related to
segment counting may differ from the original queue." The exact same
reasoning applies to integrity segments: a stacked driver's underlying
queue can have tighter virt_boundary_mask, seg_boundary_mask, or
max_segment_size than the top queue, in which case
blk_rq_count_integrity_sg() against the bottom queue produces a
different count than the cached rq->nr_integrity_segments inherited
from the source request by blk_rq_prep_clone().
When the cached count is lower than the bottom queue's actual count,
blk_rq_map_integrity_sg() trips
BUG_ON(segments > rq->nr_integrity_segments);
on dispatch. The same families of stacked setups that motivated the
existing nr_phys_segments recompute -- dm-multipath fanning out to
nvme-rdma in particular -- can produce this.
Mirror the nr_phys_segments handling: when the request carries
integrity, recompute nr_integrity_segments against the bottom queue
and reject the request if it exceeds the bottom queue's
max_integrity_segments. blk_rq_count_integrity_sg() and
queue_max_integrity_segments() are both already available via
, which blk-mq.c includes.
This closes a latent gap in the stacking contract and brings the
integrity-segment accounting in line with the existing
phys-segment accounting.
CVSS 3.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H