Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: bttv: fix use after free error due to btv-&gt;timeout timer<br /> <br /> There may be some a race condition between timer function<br /> bttv_irq_timeout and bttv_remove. The timer is setup in<br /> probe and there is no timer_delete operation in remove<br /> function. When it hit kfree btv, the function might still be<br /> invoked, which will cause use after free bug.<br /> <br /> This bug is found by static analysis, it may be false positive.<br /> <br /> Fix it by adding del_timer_sync invoking to the remove function.<br /> <br /> cpu0 cpu1<br /> bttv_probe<br /> -&gt;timer_setup<br /> -&gt;bttv_set_dma<br /> -&gt;mod_timer;<br /> bttv_remove<br /> -&gt;kfree(btv);<br /> -&gt;bttv_irq_timeout<br /> -&gt;USE btv

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to drop meta_inode&amp;#39;s page cache in f2fs_put_super()<br /> <br /> syzbot reports a kernel bug as below:<br /> <br /> F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1<br /> kernel BUG at fs/f2fs/super.c:1639!<br /> CPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0<br /> RIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639<br /> Call Trace:<br /> generic_shutdown_super+0x161/0x3c0 fs/super.c:693<br /> kill_block_super+0x3b/0x70 fs/super.c:1646<br /> kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879<br /> deactivate_locked_super+0x9a/0x170 fs/super.c:481<br /> deactivate_super+0xde/0x100 fs/super.c:514<br /> cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254<br /> task_work_run+0x14d/0x240 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:171 [inline]<br /> exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296<br /> do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> In f2fs_put_super(), it tries to do sanity check on dirty and IO<br /> reference count of f2fs, once there is any reference count leak,<br /> it will trigger panic.<br /> <br /> The root case is, during f2fs_put_super(), if there is any IO error<br /> in f2fs_wait_on_all_pages(), we missed to truncate meta_inode&amp;#39;s page<br /> cache later, result in panic, fix this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: fix a possible null pointer dereference<br /> <br /> In versatile_panel_get_modes(), the return value of drm_mode_duplicate()<br /> is assigned to mode, which will lead to a NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix a race condition of vram buffer unref in svm code<br /> <br /> prange-&gt;svm_bo unref can happen in both mmu callback and a callback after<br /> migrate to system ram. Both are async call in different tasks. Sync svm_bo<br /> unref operation to avoid random "use-after-free".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference<br /> <br /> In tpg110_get_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a NULL pointer dereference on<br /> failure of drm_mode_duplicate(). Add a check to avoid npd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats()<br /> <br /> len is extracted from HTT message and could be an unexpected value in<br /> case errors happen, so add validation before using to avoid possible<br /> out-of-bound read in the following message iteration and parsing.<br /> <br /> The same issue also applies to ppdu_info-&gt;ppdu_stats.common.num_users,<br /> so validate it before using too.<br /> <br /> These are found during code review.<br /> <br /> Compile test only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Detect IP == ksym.end as part of BPF program<br /> <br /> Now that bpf_throw kfunc is the first such call instruction that has<br /> noreturn semantics within the verifier, this also kicks in dead code<br /> elimination in unprecedented ways. For one, any instruction following<br /> a bpf_throw call will never be marked as seen. Moreover, if a callchain<br /> ends up throwing, any instructions after the call instruction to the<br /> eventually throwing subprog in callers will also never be marked as<br /> seen.<br /> <br /> The tempting way to fix this would be to emit extra &amp;#39;int3&amp;#39; instructions<br /> which bump the jited_len of a program, and ensure that during runtime<br /> when a program throws, we can discover its boundaries even if the call<br /> instruction to bpf_throw (or to subprogs that always throw) is emitted<br /> as the final instruction in the program.<br /> <br /> An example of such a program would be this:<br /> <br /> do_something():<br /> ...<br /> r0 = 0<br /> exit<br /> <br /> foo():<br /> r1 = 0<br /> call bpf_throw<br /> r0 = 0<br /> exit<br /> <br /> bar(cond):<br /> if r1 != 0 goto pc+2<br /> call do_something<br /> exit<br /> call foo<br /> r0 = 0 // Never seen by verifier<br /> exit //<br /> <br /> main(ctx):<br /> r1 = ...<br /> call bar<br /> r0 = 0<br /> exit<br /> <br /> Here, if we do end up throwing, the stacktrace would be the following:<br /> <br /> bpf_throw<br /> foo<br /> bar<br /> main<br /> <br /> In bar, the final instruction emitted will be the call to foo, as such,<br /> the return address will be the subsequent instruction (which the JIT<br /> emits as int3 on x86). This will end up lying outside the jited_len of<br /> the program, thus, when unwinding, we will fail to discover the return<br /> address as belonging to any program and end up in a panic due to the<br /> unreliable stack unwinding of BPF programs that we never expect.<br /> <br /> To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as<br /> part of the BPF program, so that is_bpf_text_address returns true when<br /> such a case occurs, and we are able to unwind reliably when the final<br /> instruction ends up being a call instruction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix possible out-of-bound write in ath12k_wmi_ext_hal_reg_caps()<br /> <br /> reg_cap.phy_id is extracted from WMI event and could be an unexpected value<br /> in case some errors happen. As a result out-of-bound write may occur to<br /> soc-&gt;hal_reg_cap. Fix it by validating reg_cap.phy_id before using it.<br /> <br /> This is found during code review.<br /> <br /> Compile tested only.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.