Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix deadlock when converting an inline directory in nojournal mode<br /> <br /> In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock<br /> by calling ext4_handle_dirty_dirblock() when it already has taken the<br /> directory lock. There is a similar self-deadlock in<br /> ext4_incvert_inline_data_nolock() for data files which we&amp;#39;ll fix at<br /> the same time.<br /> <br /> A simple reproducer demonstrating the problem:<br /> <br /> mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64<br /> mount -t ext4 -o dirsync /dev/vdc /vdc<br /> cd /vdc<br /> mkdir file0<br /> cd file0<br /> touch file0<br /> touch file1<br /> attr -s BurnSpaceInEA -V abcde .<br /> touch supercalifragilisticexpialidocious

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/bpf: Fix buffer overflow in tcp_basertt<br /> <br /> Using sizeof(nv) or strlen(nv)+1 is correct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix null pointer dereference in ovl_get_acl_rcu()<br /> <br /> Following process:<br /> P1 P2<br /> path_openat<br /> link_path_walk<br /> may_lookup<br /> inode_permission(rcu)<br /> ovl_permission<br /> acl_permission_check<br /> check_acl<br /> get_cached_acl_rcu<br /> ovl_get_inode_acl<br /> realinode = ovl_inode_real(ovl_inode)<br /> drop_cache<br /> __dentry_kill(ovl_dentry)<br /> iput(ovl_inode)<br /> ovl_destroy_inode(ovl_inode)<br /> dput(oi-&gt;__upperdentry)<br /> dentry_kill(upperdentry)<br /> dentry_unlink_inode<br /> upperdentry-&gt;d_inode = NULL<br /> ovl_inode_upper<br /> upperdentry = ovl_i_dentry_upper(ovl_inode)<br /> d_inode(upperdentry) // returns NULL<br /> IS_POSIXACL(realinode) // NULL pointer dereference<br /> , will trigger an null pointer dereference at realinode:<br /> [ 205.472797] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000028<br /> [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted<br /> 6.3.0-12064-g2edfa098e750-dirty #1216<br /> [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300<br /> [ 205.489584] Call Trace:<br /> [ 205.489812] <br /> [ 205.490014] ovl_get_inode_acl+0x26/0x30<br /> [ 205.490466] get_cached_acl_rcu+0x61/0xa0<br /> [ 205.490908] generic_permission+0x1bf/0x4e0<br /> [ 205.491447] ovl_permission+0x79/0x1b0<br /> [ 205.491917] inode_permission+0x15e/0x2c0<br /> [ 205.492425] link_path_walk+0x115/0x550<br /> [ 205.493311] path_lookupat.isra.0+0xb2/0x200<br /> [ 205.493803] filename_lookup+0xda/0x240<br /> [ 205.495747] vfs_fstatat+0x7b/0xb0<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Use the helper ovl_i_path_realinode() to get realinode and then do<br /> non-nullptr checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: af9005: Fix null-ptr-deref in af9005_i2c_xfer<br /> <br /> In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach af9005_i2c_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/powernv/sriov: perform null check on iov before dereferencing iov<br /> <br /> Currently pointer iov is being dereferenced before the null check of iov<br /> which can lead to null pointer dereference errors. Fix this by moving the<br /> iov null check before the dereferencing.<br /> <br /> Detected using cppcheck static analysis:<br /> linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either<br /> the condition &amp;#39;!iov&amp;#39; is redundant or there is possible null pointer<br /> dereference: iov. [nullPointerRedundantCheck]<br /> num_vfs = iov-&gt;num_vfs;<br /> ^

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> refscale: Fix uninitalized use of wait_queue_head_t<br /> <br /> Running the refscale test occasionally crashes the kernel with the<br /> following error:<br /> <br /> [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8<br /> [ 8569.952900] #PF: supervisor read access in kernel mode<br /> [ 8569.952902] #PF: error_code(0x0000) - not-present page<br /> [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0<br /> [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI<br /> [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021<br /> [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190<br /> :<br /> [ 8569.952940] Call Trace:<br /> [ 8569.952941] <br /> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]<br /> [ 8569.952959] kthread+0x10e/0x130<br /> [ 8569.952966] ret_from_fork+0x1f/0x30<br /> [ 8569.952973] <br /> <br /> The likely cause is that init_waitqueue_head() is called after the call to<br /> the torture_create_kthread() function that creates the ref_scale_reader<br /> kthread. Although this init_waitqueue_head() call will very likely<br /> complete before this kthread is created and starts running, it is<br /> possible that the calling kthread will be delayed between the calls to<br /> torture_create_kthread() and init_waitqueue_head(). In this case, the<br /> new kthread will use the waitqueue head before it is properly initialized,<br /> which is not good for the kernel&amp;#39;s health and well-being.<br /> <br /> The above crash happened here:<br /> <br /> static inline void __add_wait_queue(...)<br /> {<br /> :<br /> if (!(wq-&gt;flags &amp; WQ_FLAG_PRIORITY))

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm flakey: don&amp;#39;t corrupt the zero page<br /> <br /> When we need to zero some range on a block device, the function<br /> __blkdev_issue_zero_pages submits a write bio with the bio vector pointing<br /> to the zero page. If we use dm-flakey with corrupt bio writes option, it<br /> will corrupt the content of the zero page which results in crashes of<br /> various userspace programs. Glibc assumes that memory returned by mmap is<br /> zeroed and it uses it for calloc implementation; if the newly mapped<br /> memory is not zeroed, calloc will return non-zeroed memory.<br /> <br /> Fix this bug by testing if the page is equal to ZERO_PAGE(0) and<br /> avoiding the corruption in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: bus: verify partner exists in typec_altmode_attention<br /> <br /> Some usb hubs will negotiate DisplayPort Alt mode with the device<br /> but will then negotiate a data role swap after entering the alt<br /> mode. The data role swap causes the device to unregister all alt<br /> modes, however the usb hub will still send Attention messages<br /> even after failing to reregister the Alt Mode. type_altmode_attention<br /> currently does not verify whether or not a device&amp;#39;s altmode partner<br /> exists, which results in a NULL pointer error when dereferencing<br /> the typec_altmode and typec_altmode_ops belonging to the altmode<br /> partner.<br /> <br /> Verify the presence of a device&amp;#39;s altmode partner before sending<br /> the Attention message to the Alt Mode driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx<br /> <br /> For the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoid<br /> uninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() should<br /> validate pkt_len before accessing the SKB.<br /> <br /> For example, the obtained SKB may have been badly constructed with<br /> pkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdr<br /> but after being processed in ath9k_htc_rx_msg() and passed to<br /> ath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMI<br /> command header which should be located inside its data payload.<br /> <br /> Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninit<br /> memory can be referenced.<br /> <br /> Tested on Qualcomm Atheros Communications AR9271 802.11n .<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_bcm7271: fix leak in `brcmuart_probe`<br /> <br /> Smatch reports:<br /> drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() warn:<br /> &amp;#39;baud_mux_clk&amp;#39; from clk_prepare_enable() not released on lines: 1032.<br /> <br /> The issue is fixed by using a managed clock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix data race on CQP completion stats<br /> <br /> CQP completion statistics is read lockesly in irdma_wait_event and<br /> irdma_check_cqp_progress while it can be updated in the completion<br /> thread irdma_sc_ccq_get_cqe_info on another CPU as KCSAN reports.<br /> <br /> Make completion statistics an atomic variable to reflect coherent updates<br /> to it. This will also avoid load/store tearing logic bug potentially<br /> possible by compiler optimizations.<br /> <br /> [77346.170861] BUG: KCSAN: data-race in irdma_handle_cqp_op [irdma] / irdma_sc_ccq_get_cqe_info [irdma]<br /> <br /> [77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4:<br /> [77346.171483] irdma_sc_ccq_get_cqe_info+0x27a/0x370 [irdma]<br /> [77346.171658] irdma_cqp_ce_handler+0x164/0x270 [irdma]<br /> [77346.171835] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [77346.172009] process_one_work+0x4d1/0xa40<br /> [77346.172024] worker_thread+0x319/0x700<br /> [77346.172037] kthread+0x180/0x1b0<br /> [77346.172054] ret_from_fork+0x22/0x30<br /> <br /> [77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2:<br /> [77346.172234] irdma_handle_cqp_op+0xf4/0x4b0 [irdma]<br /> [77346.172413] irdma_cqp_aeq_cmd+0x75/0xa0 [irdma]<br /> [77346.172592] irdma_create_aeq+0x390/0x45a [irdma]<br /> [77346.172769] irdma_rt_init_hw.cold+0x212/0x85d [irdma]<br /> [77346.172944] irdma_probe+0x54f/0x620 [irdma]<br /> [77346.173122] auxiliary_bus_probe+0x66/0xa0<br /> [77346.173137] really_probe+0x140/0x540<br /> [77346.173154] __driver_probe_device+0xc7/0x220<br /> [77346.173173] driver_probe_device+0x5f/0x140<br /> [77346.173190] __driver_attach+0xf0/0x2c0<br /> [77346.173208] bus_for_each_dev+0xa8/0xf0<br /> [77346.173225] driver_attach+0x29/0x30<br /> [77346.173240] bus_add_driver+0x29c/0x2f0<br /> [77346.173255] driver_register+0x10f/0x1a0<br /> [77346.173272] __auxiliary_driver_register+0xbc/0x140<br /> [77346.173287] irdma_init_module+0x55/0x1000 [irdma]<br /> [77346.173460] do_one_initcall+0x7d/0x410<br /> [77346.173475] do_init_module+0x81/0x2c0<br /> [77346.173491] load_module+0x1232/0x12c0<br /> [77346.173506] __do_sys_finit_module+0x101/0x180<br /> [77346.173522] __x64_sys_finit_module+0x3c/0x50<br /> [77346.173538] do_syscall_64+0x39/0x90<br /> [77346.173553] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [77346.173634] value changed: 0x0000000000000094 -&gt; 0x0000000000000095

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Disable preemption in bpf_perf_event_output<br /> <br /> The nesting protection in bpf_perf_event_output relies on disabled<br /> preemption, which is guaranteed for kprobes and tracepoints.<br /> <br /> However bpf_perf_event_output can be also called from uprobes context<br /> through bpf_prog_run_array_sleepable function which disables migration,<br /> but keeps preemption enabled.<br /> <br /> This can cause task to be preempted by another one inside the nesting<br /> protection and lead eventually to two tasks using same perf_sample_data<br /> buffer and cause crashes like:<br /> <br /> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)<br /> BUG: unable to handle page fault for address: ffffffff82be3eea<br /> ...<br /> Call Trace:<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x176/0x4d0<br /> ? exc_page_fault+0x132/0x230<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? perf_output_sample+0x12b/0x910<br /> ? perf_event_output+0xd0/0x1d0<br /> ? bpf_perf_event_output+0x162/0x1d0<br /> ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87<br /> ? __uprobe_perf_func+0x12b/0x540<br /> ? uprobe_dispatcher+0x2c4/0x430<br /> ? uprobe_notify_resume+0x2da/0xce0<br /> ? atomic_notifier_call_chain+0x7b/0x110<br /> ? exit_to_user_mode_prepare+0x13e/0x290<br /> ? irqentry_exit_to_user_mode+0x5/0x30<br /> ? asm_exc_int3+0x35/0x40<br /> <br /> Fixing this by disabling preemption in bpf_perf_event_output.