acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
In the Linux kernel, the following vulnerability has been resolved:
acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
Fix an issue detected by syzbot with KASAN:
BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/
core.c:416 [inline]
BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0
drivers/acpi/nfit/core.c:459
The issue occurs in cmd_to_func when the call_pkg->nd_reserved2
array is accessed without verifying that call_pkg points to a buffer
that is appropriately sized as a struct nd_cmd_pkg. This can lead
to out-of-bounds access and undefined behavior if the buffer does not
have sufficient space.
To
In the Linux kernel, the following vulnerability has been resolved:
net: lapb: increase LAPB_HEADER_LEN
It is unclear if net/lapb code is supposed to be ready for 8021q.
We can at least avoid crashes like the following :
skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
net: defer final 'struct net' free in netns dismantle
In the Linux kernel, the following vulnerability has been resolved:
net: defer final 'struct net' free in netns dismantle
Ilya reported a slab-use-after-free in dst_destroy [1]
Issue is in xfrm6_net_init() and xfrm4_net_init() :
They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.
But net structure might be freed before all the dst callbacks are
called. So when dst_destroy() calls later :
if (dst->ops->destroy)
dst->ops->destroy(dst);
dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.
See a relevant issue fixed in :
ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")
A
In the Linux kernel, the following vulnerability has been resolved:
can: hi311x: hi3110_can_ist(): fix potential use-after-free
The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr
during bus-off") removed the reporting of rxerr and txerr even in case
of correct operation (i. e. not bus-off).
The error count information added to the CAN frame after netif_rx() is
a potential use after free, since there is no guarantee that the skb
is in the same state. It might be freed or reused.
Fix the issue by postponing the netif_rx() call in case of txerr and
rxerr reporting.
netfilter: x_tables: fix LED ID check in led_tg_check()
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: fix LED ID check in led_tg_check()
Syzbot has reported the following BUG detected by KASAN:
BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70
Read of size 1 at addr ffff8881022da0c8 by task repro/5879
...
Call Trace:
<TASK>
dump_stack_lvl+0x241/0x360
? __pfx_dump_stack_lvl+0x10/0x10
? __pfx__printk+0x10/0x10
? _printk+0xd5/0x120
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x183/0x530
print_report+0x169/0x550
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x183/0x530
? __virt_addr_valid+0x45f/0x530
? __phys_addr+0xba/0x170
? s
net: hsr: avoid potential out-of-bound access in fill_frame_info()
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending
it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already,
extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]
BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
fill_frame_info net/hsr/hsr_forward.c:709 [inline]
hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235
__netdev_st
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_session_new(): fix skb reference counting
Since j1939_session_skb_queue() does an extra skb_get() for each new
skb, do the same for the initial one in j1939_session_new() to avoid
refcount underflow.
[mkl: clean up commit message]
net/ipv6: release expired exception dst cached in socket
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: release expired exception dst cached in socket
Dst objects get leaked in ip6_negative_advice() when this function is
executed for an expired IPv6 route located in the exception table. There
are several conditions that must be fulfilled for the leak to occur:
* an ICMPv6 packet indicating a change of the MTU for the path is received,
resulting in an exception dst being created
* a TCP connection that uses the exception dst for routing packets must
start timing out so that TCP begins retransmissions
* after the exception dst expires, the FIB6 garbage collector m
In the Linux kernel, the following vulnerability has been resolved:
dccp: Fix memory leak in dccp_feat_change_recv
If dccp_feat_push_confirm() fails after new value for SP feature was accepted
without reconciliation ('entry == NULL' branch), memory allocated for that value
with dccp_feat_clone_sp_val() is never freed.
Here is the kmemleak stack for this:
unreferenced object 0xffff88801d4ab488 (size 8):
comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s)
hex dump (first 8 bytes):
01 b4 4a 1d 80 88 ff ff ..J.....
backtrace:
[<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128
[<00000
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket
in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup
of the UDP kernel socket is deferred by work calling
cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking
tipc_net(net)->wq_count. However, the work decrements the
count too early before releasing the kernel socket,
unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in
clean
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
Workqueue: events smc_lgr_terminate_work [smc]
Call trace:
refcount_warn_saturate+0x9c/0x140
__smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
smc_lgr_terminate_work+0x28/0x30 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x
netfilter: ipset: Hold module reference while requesting a module
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Hold module reference while requesting a module
User space may unload ip_set.ko while it is itself requesting a set type
backend module, leading to a kernel crash. The race condition may be
provoked by inserting an mdelay() right after the nfnl_unlock() call.
geneve: do not assume mac header is set in geneve_xmit_skb()
In the Linux kernel, the following vulnerability has been resolved:
geneve: do not assume mac header is set in geneve_xmit_skb()
We should not assume mac header is set in output path.
Use skb_eth_hdr() instead of eth_hdr() to fix the issue.
sysbot reported the following :
WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]
WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]
WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]
WARNING: CPU: 0 PID: 11635 at include/linux/skb
In the Linux kernel, the following vulnerability has been resolved:
gpio: grgpio: Add NULL check in grgpio_probe
devm_kasprintf() can return a NULL pointer on failure,but this
returned value in grgpio_probe is not checked.
Add NULL check in grgpio_probe, to handle kernel NULL
pointer dereference error.
tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.
Potential problems with this strategy are as follows:
- If the actual sent bytes are smaller than tosend, we need to charge some
bytes back, as in line 487, which is okay but seems not clean.
- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may
miss uncharging (msg->sg.size - apply_bytes) bytes.
[...]
415 tosend = msg->sg.size;
416 if (psock
scsi: sg: Fix slab-use-after-free read in sg_release()
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sg_release()
Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30
kernel/locking/lockdep.c:5838
__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912
sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is
called before releasing the open_rel_lock mutex. The kref_put() call may
decrement the reference count of sfp to zero, triggering its cleanup
through sg_remove_sfp(). This cleanup inc
ocfs2: free inode when ocfs2_get_init_inode() fails
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: free inode when ocfs2_get_init_inode() fails
syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826
("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when
new_inode() succeeded and dquot_initialize() failed.
HID: wacom: fix when get product name maybe null pointer
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: fix when get product name maybe null pointer
Due to incorrect dev->product reporting by certain devices, null
pointer dereferences occur when dev->product is empty, leading to
potential system crashes.
This issue was found on EXCELSIOR DL37-D05 device with
Loongson-LS3A6000-7A2000-DL37 motherboard.
Kernel logs:
[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci
[ 56.671638] usb 4-3: string descriptor 0 read error: -22
[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07
[ 56.671647] usb 4-3: Ne
ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
An offset from client could be a negative value, It could lead
to an out-of-bounds read from the stream_buf.
Note that this issue is coming when setting
'vfs objects = streams_xattr parameter' in ksmbd.conf.
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
An offset from client could be a negative value, It could allows
to write data outside the bounds of the allocated buffer.
Note that this issue is coming when setting
'vfs objects = streams_xattr parameter' in ksmbd.conf.