Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: bdisp: Add missing check for create_workqueue<br /> <br /> Add the check for the return value of the create_workqueue<br /> in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/bpf: Fix fout leak in hbm&amp;#39;s run_bpf_prog<br /> <br /> Fix fout being fopen&amp;#39;ed but then not subsequently fclose&amp;#39;d. In the affected<br /> branch, fout is otherwise going out of scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale<br /> <br /> Running the &amp;#39;kfree_rcu_test&amp;#39; test case [1] results in a splat [2].<br /> The root cause is the kfree_scale_thread thread(s) continue running<br /> after unloading the rcuscale module. This commit fixes that isue by<br /> invoking kfree_scale_cleanup() from rcu_scale_cleanup() when removing<br /> the rcuscale module.<br /> <br /> [1] modprobe rcuscale kfree_rcu_test=1<br /> // After some time<br /> rmmod rcuscale<br /> rmmod torture<br /> <br /> [2] BUG: unable to handle page fault for address: ffffffffc0601a87<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0<br /> Oops: 0010 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:0xffffffffc0601a87<br /> Code: Unable to access opcode bytes at 0xffffffffc0601a5d.<br /> RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297<br /> RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de<br /> RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe<br /> FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? kvfree_call_rcu+0xf0/0x3a0<br /> ? kthread+0xf3/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ? ret_from_fork+0x1f/0x30<br /> <br /> Modules linked in: rfkill sunrpc ... [last unloaded: torture]<br /> CR2: ffffffffc0601a87<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix NULL dereference on q-&gt;elevator in blk_mq_elv_switch_none<br /> <br /> After grabbing q-&gt;sysfs_lock, q-&gt;elevator may become NULL because of<br /> elevator switch.<br /> <br /> Fix the NULL dereference on q-&gt;elevator by checking it with lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btrtl: check for NULL in btrtl_set_quirks()<br /> <br /> The btrtl_set_quirks() has accessed btrtl_dev-&gt;ic_info-&gt;lmp_subver since<br /> b8e482d02513. However, if installing a Realtek Bluetooth controller<br /> without the driver supported, it will hit the NULL point accessed.<br /> <br /> Add a check for NULL to avoid the Kernel Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix null-ptr-deref on inode-&gt;i_op in ntfs_lookup()<br /> <br /> Syzbot reported a null-ptr-deref bug:<br /> <br /> ntfs3: loop0: Different NTFS&amp;#39; sector size (1024) and media sector size<br /> (512)<br /> ntfs3: loop0: Mark volume as dirty due to NTFS errors<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]<br /> RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796<br /> Call Trace:<br /> <br /> d_splice_alias+0x122/0x3b0 fs/dcache.c:3191<br /> lookup_open fs/namei.c:3391 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x10e6/0x2df0 fs/namei.c:3688<br /> do_filp_open+0x264/0x4f0 fs/namei.c:3718<br /> do_sys_openat2+0x124/0x4e0 fs/open.c:1310<br /> do_sys_open fs/open.c:1326 [inline]<br /> __do_sys_open fs/open.c:1334 [inline]<br /> __se_sys_open fs/open.c:1330 [inline]<br /> __x64_sys_open+0x221/0x270 fs/open.c:1330<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> If the MFT record of ntfs inode is not a base record, inode-&gt;i_op can be<br /> NULL. And a null-ptr-deref may happen:<br /> <br /> ntfs_lookup()<br /> dir_search_u() # inode-&gt;i_op is set to NULL<br /> d_splice_alias()<br /> __d_add()<br /> d_flags_for_inode() # inode-&gt;i_op-&gt;get_link null-ptr-deref<br /> <br /> Fix this by adding a Check on inode-&gt;i_op before calling the<br /> d_splice_alias() function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Do not update file length for failed writes to inline files<br /> <br /> When write to inline file fails (or happens only partly), we still<br /> updated length of inline data as if the whole write succeeded. Fix the<br /> update of length of inline data to happen only if the write succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: check send stream number after wait_for_sndbuf<br /> <br /> This patch fixes a corner case where the asoc out stream count may change<br /> after wait_for_sndbuf.<br /> <br /> When the main thread in the client starts a connection, if its out stream<br /> count is set to N while the in stream count in the server is set to N - 2,<br /> another thread in the client keeps sending the msgs with stream number<br /> N - 1, and waits for sndbuf before processing INIT_ACK.<br /> <br /> However, after processing INIT_ACK, the out stream count in the client is<br /> shrunk to N - 2, the same to the in stream count in the server. The crash<br /> occurs when the thread waiting for sndbuf is awake and sends the msg in a<br /> non-existing stream(N - 1), the call trace is as below:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]<br /> Call Trace:<br /> <br /> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]<br /> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]<br /> sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170<br /> sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163<br /> sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868<br /> sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026<br /> inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825<br /> sock_sendmsg_nosec net/socket.c:722 [inline]<br /> sock_sendmsg+0xde/0x190 net/socket.c:745<br /> <br /> The fix is to add an unlikely check for the send stream number after the<br /> thread wakes up from the wait_for_sndbuf.

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 /> drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()<br /> <br /> Commit 041879b12ddb ("drivers: staging: rtl8192bs: Fix deadlock in<br /> rtw_joinbss_event_prehandle()") besides fixing the deadlock also<br /> modified _rtw_join_timeout_handler() to use spin_[un]lock_irq()<br /> instead of spin_[un]lock_bh().<br /> <br /> _rtw_join_timeout_handler() calls rtw_do_join() which takes<br /> pmlmepriv-&gt;scanned_queue.lock using spin_[un]lock_bh(). This<br /> spin_unlock_bh() call re-enables softirqs which triggers an oops in<br /> kernel/softirq.c: __local_bh_enable_ip() when it calls<br /> lockdep_assert_irqs_enabled():<br /> <br /> [ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100<br /> ...<br /> [ 244.509022] Call Trace:<br /> [ 244.509048] <br /> [ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs]<br /> [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]<br /> [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]<br /> [ 244.510076] call_timer_fn+0x95/0x2a0<br /> [ 244.510200] __run_timers.part.0+0x1da/0x2d0<br /> <br /> This oops is causd by the switch to spin_[un]lock_irq() which disables<br /> the IRQs for the entire duration of _rtw_join_timeout_handler().<br /> <br /> Disabling the IRQs is not necessary since all code taking this lock<br /> runs from either user contexts or from softirqs, switch back to<br /> spin_[un]lock_bh() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write<br /> <br /> During the sysfs firmware write process, a use-after-free read warning is<br /> logged from the lpfc_wr_object() routine:<br /> <br /> BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]<br /> Use-after-free read at 0x0000000000cf164d (in kfence-#111):<br /> lpfc_wr_object+0x235/0x310 [lpfc]<br /> lpfc_write_firmware.cold+0x206/0x30d [lpfc]<br /> lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]<br /> lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]<br /> kernfs_fop_write_iter+0x121/0x1b0<br /> new_sync_write+0x11c/0x1b0<br /> vfs_write+0x1ef/0x280<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x59/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The driver accessed wr_object pointer data, which was initialized into<br /> mailbox payload memory, after the mailbox object was released back to the<br /> mailbox pool.<br /> <br /> Fix by moving the mailbox free calls to the end of the routine ensuring<br /> that we don&amp;#39;t reference internal mailbox memory after release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: check for null return of devm_kzalloc() in dpu_writeback_init()<br /> <br /> Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might<br /> be NULL and will cause null pointer dereference later.<br /> <br /> Therefore, it might be better to check it and directly return -ENOMEM.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/512277/<br /> [DB: fixed typo in commit message]