Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix usage slab after free<br /> <br /> [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147<br /> <br /> [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1<br /> [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000016] Call Trace:<br /> [ +0.000008] <br /> [ +0.000009] dump_stack_lvl+0x76/0xa0<br /> [ +0.000017] print_report+0xce/0x5f0<br /> [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000019] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200<br /> [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000019] kasan_report+0xbe/0x110<br /> [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000023] __asan_report_load8_noabort+0x14/0x30<br /> [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_write+0x14/0x30<br /> [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_write+0x14/0x30<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? enable_work+0x124/0x220<br /> [ +0.000015] ? __pfx_enable_work+0x10/0x10<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? free_large_kmalloc+0x85/0xf0<br /> [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]<br /> [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]<br /> [ +0.000735] ? __kasan_check_read+0x11/0x20<br /> [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]<br /> [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]<br /> [ +0.000679] ? mutex_unlock+0x80/0xe0<br /> [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]<br /> [ +0.000662] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __kasan_check_write+0x14/0x30<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? mutex_unlock+0x80/0xe0<br /> [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]<br /> [ +0.000663] drm_minor_release+0xc9/0x140 [drm]<br /> [ +0.000081] drm_release+0x1fd/0x390 [drm]<br /> [ +0.000082] __fput+0x36c/0xad0<br /> [ +0.000018] __fput_sync+0x3c/0x50<br /> [ +0.000014] __x64_sys_close+0x7d/0xe0<br /> [ +0.000014] x64_sys_call+0x1bc6/0x2680<br /> [ +0.000014] do_syscall_64+0x70/0x130<br /> [ +0.000014] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190<br /> [ +0.000015] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? irqentry_exit+0x43/0x50<br /> [ +0.000012] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? exc_page_fault+0x7c/0x110<br /> [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ +0.000014] RIP: 0033:0x7ffff7b14f67<br /> [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff<br /> [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003<br /> [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67<br /> [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003<br /> [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000<br /> [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8<br /> [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040<br /> [ +0.000020] <br /> <br /> [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:<br /> [ +0.000014] kasan_save_stack+0x28/0x60<br /> [ +0.000008] kasan_save_track+0x18/0x70<br /> [ +0.000007] kasan_save_alloc_info+0x38/0x60<br /> [ +0.000007] __kasan_kmalloc+0xc1/0xd0<br /> [ +0.000007] kmalloc_trace_noprof+0x180/0x380<br /> [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]<br /> [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]<br /> [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]<br /> [ +0.000662] amdgpu_pci_p<br /> ---truncated---

A vulnerability classified as critical was found in Overtek OT-E801G OTE801G65.1.1.0. This vulnerability affects unknown code of the file /diag_ping.cmd?action=test&amp;interface=ppp0.1&amp;ipaddr=8.8.8.8%26%26cat%20/etc/passwd&amp;ipversion=4&amp;sessionKey=test. The manipulation leads to os command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as problematic has been found in Amcrest IP2M-841B, IP2M-841W, IPC-IP2M-841B, IPC-IP3M-943B, IPC-IP3M-943S, IPC-IP3M-HX2B and IPC-IPM-721S up to 20241211. This affects an unknown part of the file /web_caps/webCapsConfig of the component Web Interface. The manipulation leads to information disclosure. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Skip Rx TID cleanup for self peer<br /> <br /> During peer create, dp setup for the peer is done where Rx TID is<br /> updated for all the TIDs. Peer object for self peer will not go through<br /> dp setup.<br /> <br /> When core halts, dp cleanup is done for all the peers. While cleanup,<br /> rx_tid::ab is accessed which causes below stack trace for self peer.<br /> <br /> WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851<br /> Call Trace:<br /> __warn+0x7b/0x1a0<br /> ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]<br /> report_bug+0x10b/0x200<br /> handle_bug+0x3f/0x70<br /> exc_invalid_op+0x13/0x60<br /> asm_exc_invalid_op+0x16/0x20<br /> ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]<br /> ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]<br /> ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]<br /> ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]<br /> ath12k_core_halt+0x3b/0x100 [ath12k]<br /> ath12k_core_reset+0x494/0x4c0 [ath12k]<br /> <br /> sta object in peer will be updated when remote peer is created. Hence<br /> use peer::sta to detect the self peer and skip the cleanup.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: change folios array from kmalloc to kvmalloc<br /> <br /> When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,<br /> page_alloc only support 4MB.<br /> If above this, trigger this warn and return NULL.<br /> <br /> udmabuf can change size limit, if change it to 3072(3GB), and then alloc<br /> 3GB udmabuf, will fail create.<br /> <br /> [ 4080.876581] ------------[ cut here ]------------<br /> [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350<br /> [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350<br /> [ 4080.879470] Call Trace:<br /> [ 4080.879473] <br /> [ 4080.879473] ? __alloc_pages+0x2c8/0x350<br /> [ 4080.879475] ? __warn.cold+0x8e/0xe8<br /> [ 4080.880647] ? __alloc_pages+0x2c8/0x350<br /> [ 4080.880909] ? report_bug+0xff/0x140<br /> [ 4080.881175] ? handle_bug+0x3c/0x80<br /> [ 4080.881556] ? exc_invalid_op+0x17/0x70<br /> [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 4080.882077] ? udmabuf_create+0x131/0x400<br /> <br /> Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hyperv: streamline driver probe to avoid devres issues<br /> <br /> It was found that unloading &amp;#39;hid_hyperv&amp;#39; module results in a devres<br /> complaint:<br /> <br /> ...<br /> hv_vmbus: unregistering driver hid_hyperv<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0<br /> ...<br /> Call Trace:<br /> <br /> ? devres_release_group+0x1f2/0x2c0<br /> ? __warn+0xd1/0x1c0<br /> ? devres_release_group+0x1f2/0x2c0<br /> ? report_bug+0x32a/0x3c0<br /> ? handle_bug+0x53/0xa0<br /> ? exc_invalid_op+0x18/0x50<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? devres_release_group+0x1f2/0x2c0<br /> ? devres_release_group+0x90/0x2c0<br /> ? rcu_is_watching+0x15/0xb0<br /> ? __pfx_devres_release_group+0x10/0x10<br /> hid_device_remove+0xf5/0x220<br /> device_release_driver_internal+0x371/0x540<br /> ? klist_put+0xf3/0x170<br /> bus_remove_device+0x1f1/0x3f0<br /> device_del+0x33f/0x8c0<br /> ? __pfx_device_del+0x10/0x10<br /> ? cleanup_srcu_struct+0x337/0x500<br /> hid_destroy_device+0xc8/0x130<br /> mousevsc_remove+0xd2/0x1d0 [hid_hyperv]<br /> device_release_driver_internal+0x371/0x540<br /> driver_detach+0xc5/0x180<br /> bus_remove_driver+0x11e/0x2a0<br /> ? __mutex_unlock_slowpath+0x160/0x5e0<br /> vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]<br /> ...<br /> <br /> And the issue seems to be that the corresponding devres group is not<br /> allocated. Normally, devres_open_group() is called from<br /> __hid_device_probe() but Hyper-V HID driver overrides &amp;#39;hid_dev-&gt;driver&amp;#39;<br /> with &amp;#39;mousevsc_hid_driver&amp;#39; stub and basically re-implements<br /> __hid_device_probe() by calling hid_parse() and hid_hw_start() but not<br /> devres_open_group(). hid_device_probe() does not call __hid_device_probe()<br /> for it. Later, when the driver is removed, hid_device_remove() calls<br /> devres_release_group() as it doesn&amp;#39;t check whether hdev-&gt;driver was<br /> initially overridden or not.<br /> <br /> The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure<br /> timely release of driver-allocated resources") but the commit itself seems<br /> to be correct.<br /> <br /> Fix the issue by dropping the &amp;#39;hid_dev-&gt;driver&amp;#39; override and using<br /> hid_register_driver()/hid_unregister_driver() instead. Alternatively, it<br /> would have been possible to rely on the default handling but<br /> HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn&amp;#39;t seem to work<br /> for mousevsc as-is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix missed RCU barrier on deoffloading<br /> <br /> Currently, running rcutorture test with torture_type=rcu fwd_progress=8<br /> n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60<br /> test_boost=2, will trigger the following warning:<br /> <br /> WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> Call Trace:<br /> <br /> ? __warn+0x7e/0x120<br /> ? rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> ? report_bug+0x18e/0x1a0<br /> ? handle_bug+0x3d/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> rcu_nocb_cpu_deoffload+0x70/0xa0<br /> rcu_nocb_toggle+0x136/0x1c0<br /> ? __pfx_rcu_nocb_toggle+0x10/0x10<br /> kthread+0xd1/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> CPU0 CPU2 CPU3<br /> //rcu_nocb_toggle //nocb_cb_wait //rcutorture<br /> <br /> // deoffload CPU1 // process CPU1&amp;#39;s rdp<br /> rcu_barrier()<br /> rcu_segcblist_entrain()<br /> rcu_segcblist_add_len(1);<br /> // len == 2<br /> // enqueue barrier<br /> // callback to CPU1&amp;#39;s<br /> // rdp-&gt;cblist<br /> rcu_do_batch()<br /> // invoke CPU1&amp;#39;s rdp-&gt;cblist<br /> // callback<br /> rcu_barrier_callback()<br /> rcu_barrier()<br /> mutex_lock(&amp;rcu_state.barrier_mutex);<br /> // still see len == 2<br /> // enqueue barrier callback<br /> // to CPU1&amp;#39;s rdp-&gt;cblist<br /> rcu_segcblist_entrain()<br /> rcu_segcblist_add_len(1);<br /> // len == 3<br /> // decrement len<br /> rcu_segcblist_add_len(-2);<br /> kthread_parkme()<br /> <br /> // CPU1&amp;#39;s rdp-&gt;cblist len == 1<br /> // Warn because there is<br /> // still a pending barrier<br /> // trigger warning<br /> WARN_ON_ONCE(rcu_segcblist_n_cbs(&amp;rdp-&gt;cblist));<br /> cpus_read_unlock();<br /> <br /> // wait CPU1 to comes online and<br /> // invoke barrier callback on<br /> // CPU1 rdp&amp;#39;s-&gt;cblist<br /> wait_for_completion(&amp;rcu_state.barrier_completion);<br /> // deoffload CPU4<br /> cpus_read_lock()<br /> rcu_barrier()<br /> mutex_lock(&amp;rcu_state.barrier_mutex);<br /> // block on barrier_mutex<br /> // wait rcu_barrier() on<br /> // CPU3 to unlock barrier_mutex<br /> // but CPU3 unlock barrier_mutex<br /> // need to wait CPU1 comes online<br /> // when CPU1 going online will block on cpus_write_lock<br /> <br /> The above scenario will not only trigger a WARN_ON_ONCE(), but also<br /> trigger a deadlock.<br /> <br /> Thanks to nocb locking, a second racing rcu_barrier() on an offline CPU<br /> will either observe the decremented callback counter down to 0 and spare<br /> the callback enqueue, or rcuo will observe the new callback and keep<br /> rdp-&gt;nocb_cb_sleep to false.<br /> <br /> Therefore check rdp-&gt;nocb_cb_sleep before parking to make sure no<br /> further rcu_barrier() is waiting on the rdp.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()<br /> <br /> If we fail to allocate memory for cb_data by kmalloc, the memory<br /> allocation for eve_data is never freed, add the missing kfree()<br /> in the error handling path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: don&amp;#39;t query the device logical block size multiple times<br /> <br /> Devices block sizes may change. One of these cases is a loop device by<br /> using ioctl LOOP_SET_BLOCK_SIZE.<br /> <br /> While this may cause other issues like IO being rejected, in the case of<br /> hfsplus, it will allocate a block by using that size and potentially write<br /> out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the<br /> latter function reads a different io_size.<br /> <br /> Using a new min_io_size initally set to sb_min_blocksize works for the<br /> purposes of the original fix, since it will be set to the max between<br /> HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the<br /> max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not<br /> initialized.<br /> <br /> Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024<br /> and 4096.<br /> <br /> The produced KASAN report before the fix looks like this:<br /> <br /> [ 419.944641] ==================================================================<br /> [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a<br /> [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678<br /> [ 419.947612]<br /> [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84<br /> [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> [ 419.950035] Call Trace:<br /> [ 419.950384] <br /> [ 419.950676] dump_stack_lvl+0x57/0x78<br /> [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a<br /> [ 419.951830] print_report+0x14c/0x49e<br /> [ 419.952361] ? __virt_addr_valid+0x267/0x278<br /> [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d<br /> [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a<br /> [ 419.954231] kasan_report+0x89/0xb0<br /> [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a<br /> [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a<br /> [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10<br /> [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9<br /> [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e<br /> [ 419.957772] hfsplus_fill_super+0x348/0x1590<br /> [ 419.958355] ? hlock_class+0x4c/0x109<br /> [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10<br /> [ 419.959499] ? __pfx_string+0x10/0x10<br /> [ 419.960006] ? lock_acquire+0x3e2/0x454<br /> [ 419.960532] ? bdev_name.constprop.0+0xce/0x243<br /> [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10<br /> [ 419.961799] ? pointer+0x3f0/0x62f<br /> [ 419.962277] ? __pfx_pointer+0x10/0x10<br /> [ 419.962761] ? vsnprintf+0x6c4/0xfba<br /> [ 419.963178] ? __pfx_vsnprintf+0x10/0x10<br /> [ 419.963621] ? setup_bdev_super+0x376/0x3b3<br /> [ 419.964029] ? snprintf+0x9d/0xd2<br /> [ 419.964344] ? __pfx_snprintf+0x10/0x10<br /> [ 419.964675] ? lock_acquired+0x45c/0x5e9<br /> [ 419.965016] ? set_blocksize+0x139/0x1c1<br /> [ 419.965381] ? sb_set_blocksize+0x6d/0xae<br /> [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10<br /> [ 419.966179] mount_bdev+0x12f/0x1bf<br /> [ 419.966512] ? __pfx_mount_bdev+0x10/0x10<br /> [ 419.966886] ? vfs_parse_fs_string+0xce/0x111<br /> [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10<br /> [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10<br /> [ 419.968073] legacy_get_tree+0x104/0x178<br /> [ 419.968414] vfs_get_tree+0x86/0x296<br /> [ 419.968751] path_mount+0xba3/0xd0b<br /> [ 419.969157] ? __pfx_path_mount+0x10/0x10<br /> [ 419.969594] ? kmem_cache_free+0x1e2/0x260<br /> [ 419.970311] do_mount+0x99/0xe0<br /> [ 419.970630] ? __pfx_do_mount+0x10/0x10<br /> [ 419.971008] __do_sys_mount+0x199/0x1c9<br /> [ 419.971397] do_syscall_64+0xd0/0x135<br /> [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 419.972233] RIP: 0033:0x7c3cb812972e<br /> [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48<br /> [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5<br /> [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e<br /> [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Fix NULL pointer dereference in object-&gt;file<br /> <br /> At present, the object-&gt;file has the NULL pointer dereference problem in<br /> ondemand-mode. The root cause is that the allocated fd and object-&gt;file<br /> lifetime are inconsistent, and the user-space invocation to anon_fd uses<br /> object-&gt;file. Following is the process that triggers the issue:<br /> <br /> [write fd] [umount]<br /> cachefiles_ondemand_fd_write_iter<br /> fscache_cookie_state_machine<br /> cachefiles_withdraw_cookie<br /> if (!file) return -ENOBUFS<br /> cachefiles_clean_up_object<br /> cachefiles_unmark_inode_in_use<br /> fput(object-&gt;file)<br /> object-&gt;file = NULL<br /> // file NULL pointer dereference!<br /> __cachefiles_write(..., file, ...)<br /> <br /> Fix this issue by add an additional reference count to the object-&gt;file<br /> before write/llseek, and decrement after it finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()<br /> <br /> kmalloc may fail, return value might be NULL and will cause<br /> NULL pointer dereference. Add check NULL return of kmalloc in<br /> btc_fw_set_monreg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cw1200: Fix potential NULL dereference<br /> <br /> A recent refactoring was identified by static analysis to<br /> cause a potential NULL dereference, fix this!