| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
slimbus: qcom-ngd: cleanup in probe error path
Add proper error path in probe() to cleanup resources previously
acquired/allocated to fix warnings visible during probe deferral:
notifier callback qcom_slim_ngd_ssr_notify already registered
WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90
Modules linked in:
CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380
Call trace:
notifier_chain_register+0x5c/0x90
srcu_notifier_chain_register+0x44/0x90
qcom_register_ssr_notifier+0x38/0x4c
qcom_slim_ngd_ctrl_probe+0xd8/0x400
platform_probe+0x6c/0xe0
really_probe+0xbc/0x2d4
__driver_probe_device+0x78/0xe0
driver_probe_device+0x3c/0x12c
__device_attach_driver+0xb8/0x120
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x88/0xc0
process_one_work+0x1d4/0x320
worker_thread+0x2cc/0x44c
kthread+0x110/0x114
ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 – len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510
[ 1513.267944] Modules linked in: <snip>
[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu
[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510
<-snip->
[ 1513.267982] Call Trace:
[ 1513.267986] snprintf+0x45/0x70
[ 1513.267990] ? disk_name+0x71/0xa0
[ 1513.267993] dump_zones+0x114/0x240 [raid0]
[ 1513.267996] ? _cond_resched+0x19/0x40
[ 1513.267998] raid0_run+0x19e/0x270 [raid0]
[ 1513.268000] md_run+0x5e0/0xc50
[ 1513.268003] ? security_capable+0x3f/0x60
[ 1513.268005] do_md_run+0x19/0x110
[ 1513.268006] md_ioctl+0x195e/0x1f90
[ 1513.268007] blkdev_ioctl+0x91f/0x9f0
[ 1513.268010] block_ioctl+0x3d/0x50
[ 1513.268012] do_vfs_ioctl+0xa9/0x640
[ 1513.268014] ? __fput+0x162/0x260
[ 1513.268016] ksys_ioctl+0x75/0x80
[ 1513.268017] __x64_sys_ioctl+0x1a/0x20
[ 1513.268019] do_syscall_64+0x5e/0x200
[ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9 |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix extent map use-after-free when handling missing device in read_one_chunk
Store the error code before freeing the extent_map. Though it's
reference counted structure, in that function it's the first and last
allocation so this would lead to a potential use-after-free.
The error can happen eg. when chunk is stored on a missing device and
the degraded mount option is missing.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721 |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/omap: Fix buffer overflow in debugfs
There are two issues here:
1) The "len" variable needs to be checked before the very first write.
Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a
buffer overflow.
2) The snprintf() function returns the number of bytes that *would* have
been copied if there were enough space. But we want to know the
number of bytes which were *actually* copied so use scnprintf()
instead. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: sof_es8336: fix possible use-after-free in sof_es8336_remove()
sof_es8336_remove() calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This
means that the callback function may still be running after
the driver's remove function has finished, which would result
in a use-after-free.
Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain
space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read
when mounting corrupt file system image.
ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this
three tags will read data during scan, tag length couldn't less than data length
which will read. |
| In the Linux kernel, the following vulnerability has been resolved:
ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed
If the initialization fails in calling addrconf_init_net(), devconf_all is
the pointer that has been released. Then ip6mr_sk_done() is called to
release the net, accessing devconf->mc_forwarding directly causes invalid
pointer access.
The process is as follows:
setup_net()
ops_init()
addrconf_init_net()
all = kmemdup(...) ---> alloc "all"
...
net->ipv6.devconf_all = all;
__addrconf_sysctl_register() ---> failed
...
kfree(all); ---> ipv6.devconf_all invalid
...
ops_exit_list()
...
ip6mr_sk_done()
devconf = net->ipv6.devconf_all;
//devconf is invalid pointer
if (!devconf || !atomic_read(&devconf->mc_forwarding))
The following is the Call Trace information:
BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0
Read of size 4 at addr ffff888075508e88 by task ip/14554
Call Trace:
<TASK>
dump_stack_lvl+0x8e/0xd1
print_report+0x155/0x454
kasan_report+0xba/0x1f0
kasan_check_range+0x35/0x1b0
ip6mr_sk_done+0x112/0x3a0
rawv6_close+0x48/0x70
inet_release+0x109/0x230
inet6_release+0x4c/0x70
sock_release+0x87/0x1b0
igmp6_net_exit+0x6b/0x170
ops_exit_list+0xb0/0x170
setup_net+0x7ac/0xbd0
copy_net_ns+0x2e6/0x6b0
create_new_namespaces+0x382/0xa50
unshare_nsproxy_namespaces+0xa6/0x1c0
ksys_unshare+0x3a4/0x7e0
__x64_sys_unshare+0x2d/0x40
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f7963322547
</TASK>
Allocated by task 14554:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0xa1/0xb0
__kmalloc_node_track_caller+0x4a/0xb0
kmemdup+0x28/0x60
addrconf_init_net+0x1be/0x840
ops_init+0xa5/0x410
setup_net+0x5aa/0xbd0
copy_net_ns+0x2e6/0x6b0
create_new_namespaces+0x382/0xa50
unshare_nsproxy_namespaces+0xa6/0x1c0
ksys_unshare+0x3a4/0x7e0
__x64_sys_unshare+0x2d/0x40
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Freed by task 14554:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x155/0x1b0
slab_free_freelist_hook+0x11b/0x220
__kmem_cache_free+0xa4/0x360
addrconf_init_net+0x623/0x840
ops_init+0xa5/0x410
setup_net+0x5aa/0xbd0
copy_net_ns+0x2e6/0x6b0
create_new_namespaces+0x382/0xa50
unshare_nsproxy_namespaces+0xa6/0x1c0
ksys_unshare+0x3a4/0x7e0
__x64_sys_unshare+0x2d/0x40
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
| In the Linux kernel, the following vulnerability has been resolved:
drivers: serial: jsm: fix some leaks in probe
This error path needs to unwind instead of just returning directly. |
| In the Linux kernel, the following vulnerability has been resolved:
nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
syzbot reported hung task [1]. The following program is a simplified
version of the reproducer:
int main(void)
{
int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}
When signal interrupt nbd_start_device_ioctl() waiting the condition
atomic_read(&config->recv_threads) == 0, the task can hung because it
waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when
signal interrupt nbd_start_device_ioctl(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: megachips: Fix a null pointer dereference bug
When removing the module we will get the following warning:
[ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered
[ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
[ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
[ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130
[ 31.921825] Call Trace:
[ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw]
[ 31.923139] i2c_device_remove+0x181/0x1f0
The two bridges (stdp2690, stdp4028) do not probe at the same time, so
the driver does not call ge_b850v3_resgiter() when probing, causing the
driver to try to remove the object that has not been initialized.
Fix this by checking whether both the bridges are probed. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox()
pci_get_device() will increase the reference count for the returned
'dev'. We need to call pci_dev_put() to decrease the reference count.
Since 'dev' is only used in pci_read_config_dword(), let's add
pci_dev_put() right after it. |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: trbe: remove cpuhp instance node before remove cpuhp state
cpuhp_state_add_instance() and cpuhp_state_remove_instance() should
be used in pairs. Or there will lead to the warn on
cpuhp_remove_multi_state() since the cpuhp_step list is not empty.
The following is the error log with 'rmmod coresight-trbe':
Error: Removing state 215 which has instances left.
Call trace:
__cpuhp_remove_state_cpuslocked+0x144/0x160
__cpuhp_remove_state+0xac/0x100
arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]
platform_remove+0x34/0x70
device_remove+0x54/0x90
device_release_driver_internal+0x1e4/0x250
driver_detach+0x5c/0xb0
bus_remove_driver+0x64/0xc0
driver_unregister+0x3c/0x70
platform_driver_unregister+0x20/0x30
arm_trbe_exit+0x1c/0x658 [coresight_trbe]
__arm64_sys_delete_module+0x1ac/0x24c
invoke_syscall+0x50/0x120
el0_svc_common.constprop.0+0x58/0x1a0
do_el0_svc+0x38/0xd0
el0_svc+0x2c/0xc0
el0t_64_sync_handler+0x1ac/0x1b0
el0t_64_sync+0x19c/0x1a0
---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()
The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb
in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: maps: pxa2xx-flash: fix memory leak in probe
Free 'info' upon remapping error to avoid a memory leak.
[<miquel.raynal@bootlin.com>: Reword the commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value
The return value of acpi_fetch_acpi_dev() could be NULL, which would
cause a NULL pointer dereference to occur in acpi_device_hid().
[ rjw: Subject and changelog edits, added empty line after if () ] |
| In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix potential use-after-free in jbd2_fc_wait_bufs
In 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count
which may lead to use-after-free.
So judge buffer if uptodate before put buffer head reference count. |
| In the Linux kernel, the following vulnerability has been resolved:
wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new()
Inject fault while probing module, if device_register() fails,
but the refcount of kobject is not decreased to 0, the name
allocated in dev_set_name() is leaked. Fix this by calling
put_device(), so that name can be freed in callback function
kobject_cleanup().
unreferenced object 0xffff88810152ad20 (size 8):
comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s)
hex dump (first 8 bytes):
68 77 73 69 6d 30 00 ff hwsim0..
backtrace:
[<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0
[<00000000c0228a5e>] kvasprintf+0xb5/0x140
[<00000000cff8c21f>] kvasprintf_const+0x55/0x180
[<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150
[<000000000a80b139>] dev_set_name+0xab/0xe0 |
| In the Linux kernel, the following vulnerability has been resolved:
usb: ucsi_acpi: Increase the command completion timeout
Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command
completion timeout value") increased the timeout from 5 seconds
to 60 seconds due to issues related to alternate mode discovery.
After the alternate mode discovery switch to polled mode
the timeout was reduced, but instead of being set back to
5 seconds it was reduced to 1 second.
This is causing problems when using a Lenovo ThinkPad X1 yoga gen7
connected over Type-C to a LG 27UL850-W (charging DP over Type-C).
When the monitor is already connected at boot the following error
is logged: "PPM init failed (-110)", /sys/class/typec is empty and
on unplugging the NULL pointer deref fixed earlier in this series
happens.
When the monitor is connected after boot the following error
is logged instead: "GET_CONNECTOR_STATUS failed (-110)".
Setting the timeout back to 5 seconds fixes both cases. |
| In the Linux kernel, the following vulnerability has been resolved:
video/aperture: Call sysfb_disable() before removing PCI devices
Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
before removing PCI devices. Without, simpledrm can still bind to
simple-framebuffer devices after the hardware driver has taken over
the hardware. Both drivers interfere with each other and results are
undefined.
Reported modesetting errors [1] are shown below.
---- snap ----
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008
Call Trace:
<TASK>
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_commit+0xa4/0xe0
? drm_plane_get_damage_clips.cold+0x1c/0x1c
? drm_atomic_helper_dirtyfb+0x19e/0x280
? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? drm_ioctl_kernel+0xc4/0x150
? drm_ioctl+0x246/0x3f0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? __x64_sys_ioctl+0x91/0xd0
? do_syscall_64+0x60/0xd0
? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
</TASK>
...
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e
Call Trace:
<TASK>
? memcpy_toio+0x76/0xc0
? memcpy_toio+0x1b/0xc0
? drm_fb_memcpy_toio+0x76/0xb0
? drm_fb_blit_toio+0x75/0x2b0
? simpledrm_simple_display_pipe_update+0x132/0x150
? drm_atomic_helper_commit_planes+0xb6/0x230
? drm_atomic_helper_commit_tail+0x44/0x80
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_commit+0xa4/0xe0
? drm_plane_get_damage_clips.cold+0x1c/0x1c
? drm_atomic_helper_dirtyfb+0x19e/0x280
? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? drm_ioctl_kernel+0xc4/0x150
? drm_ioctl+0x246/0x3f0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? __x64_sys_ioctl+0x91/0xd0
? do_syscall_64+0x60/0xd0
? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
</TASK>
The problem was added by commit 5e0137612430 ("video/aperture: Disable
and unregister sysfb devices via aperture helpers") to v6.0.3 and does
not exist in the mainline branch.
The mainline commit 5e0137612430 ("video/aperture: Disable and
unregister sysfb devices via aperture helpers") has been backported
from v6.0-rc1 to stable v6.0.3 from a larger patch series [2] that
reworks fbdev framebuffer ownership. The backport misses a change to
aperture_remove_conflicting_pci_devices(). Mainline itself is fine,
because the function does not exist there as a result of the patch
series.
Instead of backporting the whole series, fix the additional function. |
| In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()
Syzkaller reports a null-ptr-deref bug as follows:
======================================================
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
[...]
Call Trace:
<TASK>
vfs_parse_fs_param fs/fs_context.c:148 [inline]
vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129
vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191
generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231
do_new_mount fs/namespace.c:3036 [inline]
path_mount+0x12de/0x1e20 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
</TASK>
======================================================
According to commit "vfs: parse: deal with zero length string value",
kernel will set the param->string to null pointer in vfs_parse_fs_string()
if fs string has zero length.
Yet the problem is that, hugetlbfs_parse_param() will dereference the
param->string, without checking whether it is a null pointer. To be more
specific, if hugetlbfs_parse_param() parses an illegal mount parameter,
such as "size=,", kernel will constructs struct fs_parameter with null
pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to
hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.
This patch solves it by adding sanity check on param->string
in hugetlbfs_parse_param(). |
