🚨 CVE-2022-50378
In the Linux kernel, the following vulnerability has been resolved:

drm/meson: reorder driver deinit sequence to fix use-after-free bug

Unloading the driver triggers the following KASAN warning:

[ +0.006275] =============================================================
[ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0
[ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695

[ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1
[ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT)
[ +0.000008] Call trace:
[ +0.000007] dump_backtrace+0x1ec/0x280
[ +0.000013] show_stack+0x24/0x80
[ +0.000008] dump_stack_lvl+0x98/0xd4
[ +0.000011] print_address_description.constprop.0+0x80/0x520
[ +0.000011] print_report+0x128/0x260
[ +0.000007] kasan_report+0xb8/0xfc
[ +0.000008] __asan_report_load8_noabort+0x3c/0x50
[ +0.000010] __list_del_entry_valid+0xe0/0x1a0
[ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm]
[ +0.000172] drm_bridge_detach+0x94/0x260 [drm]
[ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm]
[ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm]
[ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm]
[ +0.000144] drm_managed_release+0x170/0x414 [drm]
[ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm]
[ +0.000143] drm_dev_put+0x20/0x30 [drm]
[ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm]
[ +0.000028] take_down_aggregate_device+0xb0/0x160
[ +0.000016] component_del+0x18c/0x360
[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
[ +0.000015] platform_remove+0x64/0xb0
[ +0.000009] device_remove+0xb8/0x154
[ +0.000009] device_release_driver_internal+0x398/0x5b0
[ +0.000009] driver_detach+0xac/0x1b0
[ +0.000009] bus_remove_driver+0x158/0x29c
[ +0.000009] driver_unregister+0x70/0xb0
[ +0.000008] platform_driver_unregister+0x20/0x2c
[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi]
[ +0.000012] __do_sys_delete_module+0x288/0x400
[ +0.000011] __arm64_sys_delete_module+0x5c/0x80
[ +0.000009] invoke_syscall+0x74/0x260
[ +0.000009] el0_svc_common.constprop.0+0xcc/0x260
[ +0.000009] do_el0_svc+0x50/0x70
[ +0.000007] el0_svc+0x68/0x1a0
[ +0.000012] el0t_64_sync_handler+0x11c/0x150
[ +0.000008] el0t_64_sync+0x18c/0x190

[ +0.000018] Allocated by task 0:
[ +0.000007] (stack is not available)

[ +0.000011] Freed by task 2695:
[ +0.000008] kasan_save_stack+0x2c/0x5c
[ +0.000011] kasan_set_track+0x2c/0x40
[ +0.000008] kasan_set_free_info+0x28/0x50
[ +0.000009] ____kasan_slab_free+0x128/0x1d4
[ +0.000008] __kasan_slab_free+0x18/0x24
[ +0.000007] slab_free_freelist_hook+0x108/0x230
[ +0.000011] kfree+0x110/0x35c
[ +0.000008] release_nodes+0xf0/0x16c
[ +0.000009] devres_release_group+0x180/0x270
[ +0.000008] component_unbind+0x128/0x1e0
[ +0.000010] component_unbind_all+0x1b8/0x264
[ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm]
[ +0.000025] take_down_aggregate_device+0xb0/0x160
[ +0.000009] component_del+0x18c/0x360
[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
[ +0.000012] platform_remove+0x64/0xb0
[ +0.000008] device_remove+0xb8/0x154
[ +0.000009] device_release_driver_internal+0x398/0x5b0
[ +0.000009] driver_detach+0xac/0x1b0
[ +0.000009] bus_remove_driver+0x158/0x29c
[ +0.000008] driver_unregister+0x70/0xb0
[ +0.000008] platform_driver_unregister+0x20/0x2c
[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi]
[ +0.000011] __do_sys_delete_module+0x288/0x400
[ +0.000010] __arm64_sys_delete_module+0x5c/0x80
[ +0.000008] invoke_syscall+0x74/0x260
[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260
[ +0.000008] do_el0_svc+0x50/0x70
[ +0.000007] el0_svc+0x68/0x1a0
[ +0.000009] el0t_64_sync_handler+0x11c/0x150
[ +0.000009] el0t_64_sync+0x18c/0x190

[ +0.000014] The buggy address belongs to the object at ffff000020c39000
---truncated---

🎖@cveNotify

🚨 CVE-2022-50407
In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/qm - increase the memory of local variables

Increase the buffer to prevent stack overflow by fuzz test. The maximum
length of the qos configuration buffer is 256 bytes. Currently, the value
of the 'val buffer' is only 32 bytes. The sscanf does not check the dest
memory length. So the 'val buffer' may stack overflow.

🎖@cveNotify

🚨 CVE-2022-50418
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()

mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets
some error, mhi_ctrl should be freed with mhi_free_controller(). But
when ath11k_mhi_read_addr_from_dt() fails, the function returns without
calling mhi_free_controller(), which will lead to a memory leak.

We can fix it by calling mhi_free_controller() when
ath11k_mhi_read_addr_from_dt() fails.

🎖@cveNotify

🚨 CVE-2022-50420
In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/hpre - fix resource leak in remove process

In hpre_remove(), when the disable operation of qm sriov failed,
the following logic should continue to be executed to release the
remaining resources that have been allocated, instead of returning
directly, otherwise there will be resource leakage.

🎖@cveNotify

🚨 CVE-2022-50442
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Validate buffer length while parsing index

indx_read is called when we have some NTFS directory operations that
need more information from the index buffers. This adds a sanity check
to make sure the returned index buffer length is legit, or we may have
some out-of-bound memory accesses.

[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320
[ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245
[ 560.898760]
[ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37
[ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 560.900170] Call Trace:
[ 560.900407] <TASK>
[ 560.900732] dump_stack_lvl+0x49/0x63
[ 560.901108] print_report.cold+0xf5/0x689
[ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320
[ 560.901716] kasan_report+0xa7/0x130
[ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320
[ 560.902208] __asan_load2+0x68/0x90
[ 560.902427] hdr_find_e.isra.0+0x10c/0x320
[ 560.902846] ? cmp_uints+0xe0/0xe0
[ 560.903363] ? cmp_sdh+0x90/0x90
[ 560.903883] ? ntfs_bread_run+0x190/0x190
[ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750
[ 560.904969] ? ntfs_fix_post_read+0xe0/0x130
[ 560.905259] ? __kasan_check_write+0x14/0x20
[ 560.905599] ? up_read+0x1a/0x90
[ 560.905853] ? indx_read+0x22c/0x380
[ 560.906096] indx_find+0x2ef/0x470
[ 560.906352] ? indx_find_buffer+0x2d0/0x2d0
[ 560.906692] ? __kasan_kmalloc+0x88/0xb0
[ 560.906977] dir_search_u+0x196/0x2f0
[ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450
[ 560.907464] ? __kasan_check_write+0x14/0x20
[ 560.907747] ? mutex_lock+0x8f/0xe0
[ 560.907970] ? __mutex_lock_slowpath+0x20/0x20
[ 560.908214] ? kmem_cache_alloc+0x143/0x4b0
[ 560.908459] ntfs_lookup+0xe0/0x100
[ 560.908788] __lookup_slow+0x116/0x220
[ 560.909050] ? lookup_fast+0x1b0/0x1b0
[ 560.909309] ? lookup_fast+0x13f/0x1b0
[ 560.909601] walk_component+0x187/0x230
[ 560.909944] link_path_walk.part.0+0x3f0/0x660
[ 560.910285] ? handle_lookup_down+0x90/0x90
[ 560.910618] ? path_init+0x642/0x6e0
[ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0
[ 560.912559] ? __alloc_file+0x114/0x170
[ 560.913008] path_openat+0x19c/0x1d10
[ 560.913419] ? getname_flags+0x73/0x2b0
[ 560.913815] ? kasan_save_stack+0x3a/0x50
[ 560.914125] ? kasan_save_stack+0x26/0x50
[ 560.914542] ? __kasan_slab_alloc+0x6d/0x90
[ 560.914924] ? kmem_cache_alloc+0x143/0x4b0
[ 560.915339] ? getname_flags+0x73/0x2b0
[ 560.915647] ? getname+0x12/0x20
[ 560.916114] ? __x64_sys_open+0x4c/0x60
[ 560.916460] ? path_lookupat.isra.0+0x230/0x230
[ 560.916867] ? __isolate_free_page+0x2e0/0x2e0
[ 560.917194] do_filp_open+0x15c/0x1f0
[ 560.917448] ? may_open_dev+0x60/0x60
[ 560.917696] ? expand_files+0xa4/0x3a0
[ 560.917923] ? __kasan_check_write+0x14/0x20
[ 560.918185] ? _raw_spin_lock+0x88/0xdb
[ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100
[ 560.918783] ? _find_next_bit+0x4a/0x130
[ 560.919026] ? _raw_spin_unlock+0x19/0x40
[ 560.919276] ? alloc_fd+0x14b/0x2d0
[ 560.919635] do_sys_openat2+0x32a/0x4b0
[ 560.920035] ? file_open_root+0x230/0x230
[ 560.920336] ? __rcu_read_unlock+0x5b/0x280
[ 560.920813] do_sys_open+0x99/0xf0
[ 560.921208] ? filp_open+0x60/0x60
[ 560.921482] ? exit_to_user_mode_prepare+0x49/0x180
[ 560.921867] __x64_sys_open+0x4c/0x60
[ 560.922128] do_syscall_64+0x3b/0x90
[ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 560.923030] RIP: 0033:0x7f7dff2e4469
[ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088
[ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002
[ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469
[ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI:
---truncated---

🎖@cveNotify

🚨 CVE-2022-50451
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix memory leak on ntfs_fill_super() error path

syzbot reported kmemleak as below:

BUG: memory leak
unreferenced object 0xffff8880122f1540 (size 32):
comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................
backtrace:
[<ffffffff81b16052>] ntfs_init_fs_context+0x22/0x1c0
[<ffffffff8164aaa7>] alloc_fs_context+0x217/0x430
[<ffffffff81626dd4>] path_mount+0x704/0x1080
[<ffffffff81627e7c>] __x64_sys_mount+0x18c/0x1d0
[<ffffffff84593e14>] do_syscall_64+0x34/0xb0
[<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

This patch fixes this issue by freeing mount options on error path of
ntfs_fill_super().

🎖@cveNotify

🚨 CVE-2022-50479
In the Linux kernel, the following vulnerability has been resolved:

drm/amd: fix potential memory leak

This patch fix potential memory leak (clk_src) when function run
into last return NULL.

s/free/kfree/ - Alex

🎖@cveNotify

🚨 CVE-2022-50507
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Validate data run offset

This adds sanity checks for data run offset. We should make sure data
run offset is legit before trying to unpack them, otherwise we may
encounter use-after-free or some unexpected memory access behaviors.

[ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570
[ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240
[ 82.941670]
[ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15
[ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 82.943720] Call Trace:
[ 82.944204] <TASK>
[ 82.944471] dump_stack_lvl+0x49/0x63
[ 82.944908] print_report.cold+0xf5/0x67b
[ 82.945141] ? __wait_on_bit+0x106/0x120
[ 82.945750] ? run_unpack+0x2e3/0x570
[ 82.946626] kasan_report+0xa7/0x120
[ 82.947046] ? run_unpack+0x2e3/0x570
[ 82.947280] __asan_load1+0x51/0x60
[ 82.947483] run_unpack+0x2e3/0x570
[ 82.947709] ? memcpy+0x4e/0x70
[ 82.947927] ? run_pack+0x7a0/0x7a0
[ 82.948158] run_unpack_ex+0xad/0x3f0
[ 82.948399] ? mi_enum_attr+0x14a/0x200
[ 82.948717] ? run_unpack+0x570/0x570
[ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0
[ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0
[ 82.949611] ? mi_read+0x262/0x2c0
[ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180
[ 82.950249] ntfs_iget5+0x632/0x1870
[ 82.950621] ? ntfs_get_block_bmap+0x70/0x70
[ 82.951192] ? evict+0x223/0x280
[ 82.951525] ? iput.part.0+0x286/0x320
[ 82.951969] ntfs_fill_super+0x1321/0x1e20
[ 82.952436] ? put_ntfs+0x1d0/0x1d0
[ 82.952822] ? vsprintf+0x20/0x20
[ 82.953188] ? mutex_unlock+0x81/0xd0
[ 82.953379] ? set_blocksize+0x95/0x150
[ 82.954001] get_tree_bdev+0x232/0x370
[ 82.954438] ? put_ntfs+0x1d0/0x1d0
[ 82.954700] ntfs_fs_get_tree+0x15/0x20
[ 82.955049] vfs_get_tree+0x4c/0x130
[ 82.955292] path_mount+0x645/0xfd0
[ 82.955615] ? putname+0x80/0xa0
[ 82.955955] ? finish_automount+0x2e0/0x2e0
[ 82.956310] ? kmem_cache_free+0x110/0x390
[ 82.956723] ? putname+0x80/0xa0
[ 82.957023] do_mount+0xd6/0xf0
[ 82.957411] ? path_mount+0xfd0/0xfd0
[ 82.957638] ? __kasan_check_write+0x14/0x20
[ 82.957948] __x64_sys_mount+0xca/0x110
[ 82.958310] do_syscall_64+0x3b/0x90
[ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 82.959341] RIP: 0033:0x7fd0d1ce948a
[ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a
[ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0
[ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020
[ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0
[ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

🎖@cveNotify

🚨 CVE-2022-50527
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix size validation for non-exclusive domains (v4)

Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the
requested memory exists, else we get a kernel oops when dereferencing "man".

v2: Make the patch standalone, i.e. not dependent on local patches.
v3: Preserve old behaviour and just check that the manager pointer is not
NULL.
v4: Complain if GTT domain requested and it is uninitialized--most likely a
bug.

🎖@cveNotify

🚨 CVE-2022-50535
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential null-deref in dm_resume

[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null

[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.

🎖@cveNotify

🚨 CVE-2022-50560
In the Linux kernel, the following vulnerability has been resolved:

drm/meson: explicitly remove aggregate driver at module unload time

Because component_master_del wasn't being called when unloading the
meson_drm module, the aggregate device would linger forever in the global
aggregate_devices list. That means when unloading and reloading the
meson_dw_hdmi module, component_add would call into
try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate
device.

This would in turn dereference some of the aggregate_device's struct
entries which point to memory automatically freed by the devres API when
unbinding the aggregate device from meson_drv_unbind, and trigger an
use-after-free bug:

[ +0.000014] =============================================================
[ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500
[ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536
[ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1
[ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT)
[ +0.000008] Call trace:
[ +0.000005] dump_backtrace+0x1ec/0x280
[ +0.000011] show_stack+0x24/0x80
[ +0.000007] dump_stack_lvl+0x98/0xd4
[ +0.000010] print_address_description.constprop.0+0x80/0x520
[ +0.000011] print_report+0x128/0x260
[ +0.000007] kasan_report+0xb8/0xfc
[ +0.000007] __asan_report_load8_noabort+0x3c/0x50
[ +0.000009] find_components+0x468/0x500
[ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390
[ +0.000009] __component_add+0x1dc/0x49c
[ +0.000009] component_add+0x20/0x30
[ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi]
[ +0.000013] platform_probe+0xd0/0x220
[ +0.000008] really_probe+0x3ac/0xa80
[ +0.000008] __driver_probe_device+0x1f8/0x400
[ +0.000008] driver_probe_device+0x68/0x1b0
[ +0.000008] __driver_attach+0x20c/0x480
[ +0.000009] bus_for_each_dev+0x114/0x1b0
[ +0.000007] driver_attach+0x48/0x64
[ +0.000009] bus_add_driver+0x390/0x564
[ +0.000007] driver_register+0x1a8/0x3e4
[ +0.000009] __platform_driver_register+0x6c/0x94
[ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi]
[ +0.000014] do_one_initcall+0xc4/0x2b0
[ +0.000008] do_init_module+0x154/0x570
[ +0.000010] load_module+0x1a78/0x1ea4
[ +0.000008] __do_sys_init_module+0x184/0x1cc
[ +0.000008] __arm64_sys_init_module+0x78/0xb0
[ +0.000008] invoke_syscall+0x74/0x260
[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260
[ +0.000009] do_el0_svc+0x50/0x70
[ +0.000008] el0_svc+0x68/0x1a0
[ +0.000009] el0t_64_sync_handler+0x11c/0x150
[ +0.000009] el0t_64_sync+0x18c/0x190

[ +0.000014] Allocated by task 902:
[ +0.000007] kasan_save_stack+0x2c/0x5c
[ +0.000009] __kasan_kmalloc+0x90/0xd0
[ +0.000007] __kmalloc_node+0x240/0x580
[ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac
[ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0
[ +0.000008] kmem_cache_alloc_node+0x1d0/0x490
[ +0.000009] __alloc_skb+0x1d4/0x310
[ +0.000010] alloc_skb_with_frags+0x8c/0x620
[ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0
[ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0
[ +0.000010] sock_sendmsg+0xcc/0x110
[ +0.000007] sock_write_iter+0x1d0/0x304
[ +0.000008] new_sync_write+0x364/0x460
[ +0.000007] vfs_write+0x420/0x5ac
[ +0.000008] ksys_write+0x19c/0x1f0
[ +0.000008] __arm64_sys_write+0x78/0xb0
[ +0.000007] invoke_syscall+0x74/0x260
[ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260
[ +0.000009] do_el0_svc+0x50/0x70
[ +0.000007] el0_svc+0x68/0x1a0
[ +0.000008] el0t_64_sync_handler+0x11c/0x150
[ +0.000008] el0t_64_sync+0x18c/0x190

[ +0.000013] Freed by task 2509:
[ +0.000008] kasan_save_stack+0x2c/0x5c
[ +0.000007] kasan_set_track+0x2c/0x40
[ +0.000008] kasan_set_free_info+0x28/0x50
[ +0.000008] ____kasan_slab_free+0x128/0x1d4
[ +0.000008] __kasan_slab_free+0x18/0x24
[ +0.000007] slab_free_freelist_hook+0x108/0x230
[ +0.000010]
---truncated---

🎖@cveNotify

🚨 CVE-2022-50627
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix monitor mode bringup crash

When the interface is brought up in monitor mode, it leads
to NULL pointer dereference crash. This crash happens when
the packet type is extracted for a SKB. This extraction
which is present in the received msdu delivery path,is
not needed for the monitor ring packets since they are
all RAW packets. Hence appending the flags with
"RX_FLAG_ONLY_MONITOR" to skip that extraction.

Observed calltrace:

Unable to handle kernel NULL pointer dereference at virtual address
0000000000000064
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048517000
[0000000000000064] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in: ath11k_pci ath11k qmi_helpers
CPU: 2 PID: 1781 Comm: napi/-271 Not tainted
6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6
Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]
lr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k]
sp : ffff80000ef5bb10
x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0
x26: ffff000014a91ed0 x25: 0000000000000000 x24: 0000000000000000
x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600
x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006
x17: 736564203634343a x16: 656e694c20657079 x15: 0000000000000143
x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8
x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff
x8 : 0000000000000003 x7 : 0000000000017fe8 x6 : ffff80000a579ce8
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052
Call trace:
ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]
ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]
ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]
ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]
ath11k_dp_service_srng+0x234/0x338 [ath11k]
ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]
__napi_poll+0x5c/0x190
napi_threaded_poll+0xf0/0x118
kthread+0xf4/0x110
ret_from_fork+0x10/0x20

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

🎖@cveNotify

🚨 CVE-2022-4993
HTML::FormHandler versions through 0.40068 for Perl allow attacker selected method dispatch and resource exhaustion because _apply_actions and add_error use error message text built from request data as a Locale::Maketext bracket notation template.

add_error hands its first argument to the language handle as the Locale::Maketext message key, and the default handle's lexicon sets `_AUTO`, so a string that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. In a bracket group the first token names a method called on the language handle and the remaining tokens are its arguments.

Three kinds of text the library did not author reach that position. _apply_actions installs a `$SIG{__WARN__}` handler that stores the warning text in `$error_message`, and a captured warning survives a successful action, so a field carrying a numeric transform turns `Argument "[sprintf,%50000000d,0]" isn't numeric` into the template; a warning quotes the submitted value verbatim, so the group is well formed and dispatches. `$error_message ||= $tobj->validate($new_value)` takes a type constraint's own failure message, which renders the rejected value through a partial dumper in bracket and comma form (Devel::PartialDump when Moose can load it, Type::Tiny's own dumper always), so a field with `apply => [ Str ]` given a parameter sent more than once, which arrives as an array, gets `Reference ["a","b"] did not pass type constraint "Str"` as its template, from a request that carries no bracket character of its own. A coercion or transform exception reaches it the same way. Beyond those, a validator whose message contains the field value puts that value in the template directly, and add_error replaces the message list with the contents of an arrayref first argument (`@message = @{$message[0]} if ref $message[0] eq 'ARRAY'`), so a value arriving as an array fills the argument slots from the same request as well.

A malformed group such as `[0]` makes the compile croak, and HTML::FormHandler::I18N::maketext and add_error each re-raise that as a die, so process() throws. A well formed group naming sprintf reaches CORE::sprintf with an attacker chosen field width. Any caller that applies a type constraint or a transform to an untrusted field, or whose validator passes an untrusted field value to add_error, can be made to throw an unhandled exception out of process(), or to allocate an arbitrary amount of memory in one request, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The dumped type constraint message is bounded to the exception, because both dumpers quote non-numeric elements so the method slot is never an attacker chosen name. The built-in messages pass fixed templates with the value in an argument slot, where it stays inert, and the built-in field types attach explicit message callbacks, so neither is affected.

🎖@cveNotify

🚨 CVE-2026-19894
A security flaw has been discovered in itsourcecode Hospital Management System 1.0. Affected is an unknown function of the file /viewmedicine.php. Performing a manipulation of the argument delid results in sql injection. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.

🎖@cveNotify

🚨 CVE-2026-73193
DBI versions before 1.652 for Perl allow a heap out-of-bounds write on 32-bit perl via an integer wraparound in the output buffer size computed by preparse.

preparse reserves its output buffer with `newSV(strlen(statement) * 7 + 16)`, budgeting seven output bytes per input byte for the longest ':p99999' expansion. The product is computed in STRLEN, which is 32 bits wide on a 32-bit perl build, so a statement of 613,566,757 bytes multiplies to 4,294,967,299, wraps modulo 2^32 to 3, and reserves 19 bytes. The parser then copies the statement out through a raw pointer with no capacity check, writing the whole 585 MB input past the end of the allocation. The 99,999 placeholder limit does not bound this path, which is reached by ordinary non-placeholder content.

Any caller that passes an untrusted statement of that length to preparse on a 32-bit perl gets a heap out-of-bounds write of attacker controlled bytes. Builds with a 64-bit STRLEN are not affected, since the wrap there needs a statement of about 2.3 exabytes.

🎖@cveNotify

🚨 CVE-2026-73194
DBI versions before 1.652 for Perl allow a heap out-of-bounds write via an unvalidated numeric placeholder that sets the binder counter in preparse.

preparse reserves seven output bytes per input byte, the width of the longest ':p99999' expansion. The ':N' branch parses the number with `atoi(src)` and assigns it to the binder counter with no range check, so a statement containing ':2147483648' leaves the counter negative (-2147483648 with glibc, where atoi wraps). Each following '?' then expands through `sprintf(start, ":p%d", idx++)` to ':p-2147483648', 14 bytes with the terminating NUL where the buffer budgets 7. The placeholder limit added in 1.650 tests the counter against 99,999, which a negative counter passes.

Any caller that preparses an untrusted statement into ':pN' style placeholders gets a heap out-of-bounds write that grows with the number of '?' marks following the poisoned placeholder. The '?' and '%s' return styles compare the parsed number against the expected sequence and error out, and are unaffected.

🎖@cveNotify

🚨 CVE-2026-74440
In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Wait on external BO kernel fences in exec IOCTL

Before arming a user job, xe_exec_ioctl() only added the VM's
dma-resv KERNEL slot as a dependency. That slot covers rebinds and
the kernel operations of the VM's private BOs, but not external BOs
(bo->vm == NULL), which carry their kernel operations (evictions,
moves, ...) in their own dma-resv KERNEL slot.

The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for
memory management operations that must complete before the BO or its
backing store may be used: any accessor is required to wait on the
KERNEL fences before touching the resv. By skipping the external BOs'
KERNEL slots, the exec path violated that contract and could schedule
a user job while a kernel operation on an external BO mapped by the VM
was still in flight, racing against it and potentially reading or
writing memory that was being moved.

Replace the VM-only dependency with an iteration over every object
locked by the exec, adding each object's KERNEL slot as a job
dependency. This covers the VM resv (rebinds and private BOs) as well
as every external BO, mirroring the drm_gpuvm_resv_add_fence() call
that later publishes the job fence to the same set of objects.
Long-running mode continues to skip this, as before.

(cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)

🎖@cveNotify

🚨 CVE-2026-74441
In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Fix race condition and ordering in port unregistration

A synchronization issue exists during port unregistration where pending
partner work items can race against workqueue destruction, leading to
use-after-free conditions:

cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:__queue_work+0x83/0x4a0
Call Trace:
<IRQ>
__cfi_delayed_work_timer_fn+0x10/0x10
run_timer_softirq+0x3b6/0xbd0
sched_clock_cpu+0xc/0x110
irq_exit_rcu+0x18d/0x330
fred_sysvec_apic_timer_interrupt+0x5e/0x80

Fix this by ensuring strict ordering and proper serialization during
teardown:

1. Move ucsi_unregister_partner() to the beginning of the teardown
sequence and protect it under the connector mutex lock.
2. Ensure all pending partner tasks are explicitly flushed and finished
before the workqueue is destroyed.
3. Switch from mod_delayed_work() to a cancel_delayed_work() and
queue_delayed_work() sequence. This guarantees that items currently marked
as pending won't be scheduled an additional time, preventing a double
release of resources which leads to the following crash:

Oops: general protection fault, probably for non-canonical address
0xdead000000000122: 0000 [#1] SMP NOPTI
Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker
RIP: 0010:ucsi_poll_worker+0x65/0x1e0
Call Trace:
<TASK>
process_scheduled_works+0x218/0x6d0
worker_thread+0x188/0x3f0
__cfi_worker_thread+0x10/0x10
kthread+0x226/0x2a0

To ensure these rules are applied identically across both the normal
teardown and the ucsi_init() error paths, consolidate the cleanup logic
into a new helper, ucsi_unregister_port().

🎖@cveNotify

🚨 CVE-2026-74442
In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure

Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while
still leaving the rest of the driver in a state that calls
vmw_vkms_cleanup() at module unload:

1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or
returning an oversized buffer -- the common case on hosts
without a VBLANK guestinfo entry -- early-returned before the
workqueue allocation.
2. alloc_ordered_workqueue() returning NULL on memory pressure.

vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which
dereferences wq->name and panics.

Fix the first case by removing the early return: vmw->vkms_enabled
is already false on the rpci-failure path so no work will ever be
queued, and allocating the workqueue unconditionally keeps the
control flow simple. Fix the second case by guarding the cleanup
with a NULL check, since alloc_ordered_workqueue() can still fail
under low memory.

🎖@cveNotify

🚨 CVE-2026-74443
In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: bound DMA command body size against suffix pointer

vmw_cmd_dma() locates the DMA suffix at

(unsigned long) &cmd->body + header->size - sizeof(*suffix)

without checking that header->size is large enough to contain both
cmd->body and the suffix. An undersized header makes the suffix
pointer underflow back into the previous command in the bounce
buffer. The verifier later writes suffix->maximumOffset, clobbering
verified fields of an already-relocated earlier command -- a TOCTOU
on the device-visible command stream that lets one command rewrite
another's GMR id, surface id, or other authenticated fields.

Reject the command if the body is too small for the suffix to fit.

🎖@cveNotify

🚨 CVE-2026-74444
In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: validate DRAW_PRIMITIVES header size before division

vmw_cmd_draw() computes

maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl);

where header->size is u32 and is taken straight from the user-supplied
command stream. When header->size is less than sizeof(cmd->body) the
unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum.
Any user-controlled cmd->body.numVertexDecls then passes the bound and
the loop dereferences decl[i] far past the end of the kernel command
bounce buffer, producing an out-of-bounds read of kernel memory.

Reject undersized headers up front.

🎖@cveNotify