drop_monitor: fix out-of-bounds write in reset_per_cpu_data()
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: fix out-of-bounds write in reset_per_cpu_data()
In reset_per_cpu_data(), al is computed as:
al = sizeof(struct net_dm_alert_msg);
al += dm_hit_limit * sizeof(struct net_dm_drop_point);
al += sizeof(struct nlattr);
skb = genlmsg_new(al, GFP_KERNEL);
...
nla = nla_reserve(skb, NLA_UNSPEC, sizeof(struct net_dm_alert_msg));
...
msg = nla_data(nla);
memset(msg, 0, al);
Because al includes sizeof(struct nlattr) (the 4-byte attribute header),
genlmsg_new() allocates al bytes of tailroom starting at nla.
However, msg points to nl
selinux: always fill AVC decision in avc_has_perm_noaudit()
In the Linux kernel, the following vulnerability has been resolved:
selinux: always fill AVC decision in avc_has_perm_noaudit()
avc_has_perm_noaudit() is documented to return a copy of the access
decision in @avd, but its early return for an empty requested permission
set leaves the buffer untouched. All callers pass an uninitialized
stack variable and afterwards feed it to avc_audit(), and the inode hook
even stores it in the per-task decision cache.
Fill in a deny-all, audit-all decision, similar to avd_init(), so every
caller receives a defined value at no cost on the hot path.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: rtd119x: Avoid division by zero
clk_get_rate() could return 0. Avoid a division by zero panic.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rsi: fix heap OOB write on key removal
When a key is removed (data == NULL), rsi_hal_load_key() runs:
memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ);
set_key is a struct rsi_set_key *, so the subscript is scaled by
sizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is
skb->data + 2560, and the memset writes 144 zero bytes starting
2.4KB past the end of the 160-byte skb data buffer, corrupting
unrelated heap objects. The intended byte offset would have been
(u8 *)set_key + FRAME_DESC_SZ.
The write fires on every DISABLE_KEY callback, so
wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver
ieee80211_set_bitrate_mask() checks if the interface is running via
ieee80211_sdata_running(), but it does not check if the interface is
still present in the driver.
When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the
call reaches drv_set_bitrate_mask() in driver-ops.h which hits
wlan1: Failed check-sdata-in-driver check, flags: 0x0
WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask
Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows
wext_ioctl_dis
drm/virtio: Fix a NULL vs ERR_PTR() bug in virtio_gpu_user_framebuffer_create()
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix a NULL vs ERR_PTR() bug in virtio_gpu_user_framebuffer_create()
Smatch complains that returning a NULL here will lead to a NULL pointer
dereference in drm_mode_addfb2(). Return an error pointer instead.
net: iptunnel: fix stale transport header during tunnel decapsulation
In the Linux kernel, the following vulnerability has been resolved:
net: iptunnel: fix stale transport header during tunnel decapsulation
Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale
transport_header offset after tunnel decapsulation.
BUG: unable to handle page fault for address: ffffed102091a42e
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__asan_load2
<IRQ>
qdisc_pkt_len_segs_init (net/core/dev.c:4145)
__dev_queue_x
s390/ipl: Fix NULL deref in kdump without re-IPL parm block
In the Linux kernel, the following vulnerability has been resolved:
s390/ipl: Fix NULL deref in kdump without re-IPL parm block
Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might
not provide an IPL parameter block. In this case, reipl_type_init()
selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL.
kdump passes the re-IPL parameter block to the dump kernel through
os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl
block checksum calculation"), the os_info entry was added only for
IPL types which initialized reipl_block_actual. That commit moved the
os_info update to machine_crash_shutdown(), maki
s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block
In the Linux kernel, the following vulnerability has been resolved:
s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block
Unlike kdump, which passes the re-IPL parameter block through os_info,
the stand-alone dump passes it through the IPL parm block address and
checksum in lowcore.
Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
provide an IPL parameter block. In this case reipl_type_init() selects
IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless,
dump_reipl_run() unconditionally dereferences it when preparing the
lowcore fields. This may happen to work by chance when address zero
conta
locking/lockdep: Invalidate stale class_cache entries for zapped classes
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Invalidate stale class_cache entries for zapped classes
syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in
hlock_class() due to an invalid class_idx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Call Trace:
<IRQ>
lock_acquire+0x106/0x3
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a
possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to
IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an
unusually large MTU.
Steps to reproduce:
1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will
be set to that MTU in ip_setup_cork.
2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be
set to device MTU (cork->fragsize) in
drm/amdgpu: skip gfx switch_power_profile during GPU reset
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: skip gfx switch_power_profile during GPU reset
During resume from GPU reset, the gfx idle work may invoke switch_power_profile
before the reset completes. This causes the following assert error because the
register access occurs without first releasing the GPU reset semaphore:
[ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0
[ 1576.768940] Call Trace:
[ 1576.768944] <TASK>
[ 1576.768953] amdgpu_device_rreg+0x21/0x50 [amdgpu]
[ 1576.769158] smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu]
[ 1576.769437] smu_cmn_send_smc_msg_with_param
scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot
For QLAFX00 the request ring is ioremapped device I/O memory
(ha->iobase + req_que_off), not DMA-coherent RAM, which is why the rest
of the FX00 path accesses it through memcpy_toio() and the wrt_reg_*
helpers. __qla2x00_alloc_iocbs() however zeroed the producer slot with a
plain memset(). On architectures such as ARM64 a regular memset() may
emit unaligned or block-zeroing instructions (e.g. DC ZVA) that are
invalid on Device memory, leading to a synchronous external abort.
Use memset_io() to clear the slot
bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL
An LWT_SEG6LOCAL program can invalidate its cached SRH with
bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(). The latter
may reallocate skb->head, leaving the per-CPU SRH pointer dangling.
Post-program SRH validation then writes through that pointer.
Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL programs so the verifier
rejects this unsafe helper combination. Other LWT program types continue
to expose the helper through lwt_out_func_proto().
net/sched: reject IDR error pointers when deleting actions
In the Linux kernel, the following vulnerability has been resolved:
net/sched: reject IDR error pointers when deleting actions
tcf_action_delete() drops the reference held by its lookup before calling
tcf_idr_delete_index() with the saved action index. An unlocked
classifier can remove that action and reserve the same IDR slot with
ERR_PTR(-EBUSY) in between.
tcf_idr_delete_index() only checks the lookup result for NULL. It
therefore treats the reservation as a tc_action and dereferences
tcfa_bindcnt. A hardware execution breakpoint was used to schedule the
interleaving without changing the kernel source. KASAN reported this
decoded tr
netfilter: ip6t_rpfilter: reject routes without inet6_dev
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_rpfilter: reject routes without inet6_dev
ip6_route_lookup() can return an error-free route whose rt6i_idev is
NULL. Lowering an external nexthop device's MTU below IPV6_MIN_MTU tears
down its inet6_dev while fib6_ifdown() leaves routes using nexthop objects
in the FIB. An unprivileged user can construct this state with rtnetlink
in a private user and network namespace, then trigger a NULL dereference
through an IPv6 rpfilter lookup:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000
KASAN: null-ptr-deref in range [0
vlan: require the MAC header to be present in __vlan_insert_inner_tag()
In the Linux kernel, the following vulnerability has been resolved:
vlan: require the MAC header to be present in __vlan_insert_inner_tag()
__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present. Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb->data: a 12-byte
memmove plus two 2-byte stores at +12 and +14. No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().
An IFF_TUN device has hard_head
xen/netfront: drop RX packets with a short Ethernet header
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: drop RX packets with a short Ethernet header
handle_incoming_queue() pulls pull_to bytes into the head before
calling eth_type_trans(). pull_to is the length of the first RX slot,
capped at RX_COPY_THRESHOLD, and that length comes from the backend.
Nothing checks it against ETH_HLEN.
If the first slot is shorter than ETH_HLEN and more slots follow, the
head ends up shorter than an Ethernet header while skb->len is longer,
and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is
shorter than ETH_HLEN, eth_type_trans() reads the header past the end
RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept
We need to clear cep before release state_lock as siw_qp_llp_close and
siw_qp_modify->siw_qp_llp_close did.
Otherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock
is released before the error path cleanup. A concurrent ibv_modify_qp()
transitioning the QP to ERROR can race in this window:
siw_accept() ibv_modify_qp(ERROR)
---------------------- ----------------------
siw_qp_modify() fails
up_write(&qp->state_lock)
RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access
mr_check_range() validates that [iova, iova+length) falls within the
registered MR range using wraparound-prone arithmetic:
if (iova < mr->ibmr.iova ||
iova + length > mr->ibmr.iova + mr->ibmr.length)
A remote peer can craft an RDMA-Write/Read RETH so that iova + length
wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the
check. rxe_mr_iova_to_index() then computes a huge index (int idx, only
guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences
mr->page_info[huge], caus