Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: tegra: Fix memory leak in terminate_all()<br /> <br /> Terminate vdesc when terminating an ongoing transfer.<br /> This will ensure that the vdesc is present in the desc_terminated list<br /> The descriptor will be freed later in desc_free_list().<br /> <br /> This fixes the memory leaks which can happen when terminating an<br /> ongoing transfer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: betop: check shape of output reports<br /> <br /> betopff_init() only checks the total sum of the report counts for each<br /> report field to be at least 4, but hid_betopff_play() expects 4 report<br /> fields.<br /> A device advertising an output report with one field and 4 report counts<br /> would pass the check but crash the kernel with a NULL pointer dereference<br /> in hid_betopff_play().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix possible deadlock in rfcomm_sk_state_change<br /> <br /> syzbot reports a possible deadlock in rfcomm_sk_state_change [1].<br /> While rfcomm_sock_connect acquires the sk lock and waits for<br /> the rfcomm lock, rfcomm_sock_release could have the rfcomm<br /> lock and hit a deadlock for acquiring the sk lock.<br /> Here&amp;#39;s a simplified flow:<br /> <br /> rfcomm_sock_connect:<br /> lock_sock(sk)<br /> rfcomm_dlc_open:<br /> rfcomm_lock()<br /> <br /> rfcomm_sock_release:<br /> rfcomm_sock_shutdown:<br /> rfcomm_lock()<br /> __rfcomm_dlc_close:<br /> rfcomm_k_state_change:<br /> lock_sock(sk)<br /> <br /> This patch drops the sk lock before calling rfcomm_dlc_open to<br /> avoid the possible deadlock and holds sk&amp;#39;s reference count to<br /> prevent use-after-free after rfcomm_dlc_open completes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix a memory leak with reused mmap_offset<br /> <br /> drm_vma_node_allow() and drm_vma_node_revoke() should be called in<br /> balanced pairs. We call drm_vma_node_allow() once per-file everytime a<br /> user calls mmap_offset, but only call drm_vma_node_revoke once per-file<br /> on each mmap_offset. As the mmap_offset is reused by the client, the<br /> per-file vm_count may remain non-zero and the rbtree leaked.<br /> <br /> Call drm_vma_node_allow_once() instead to prevent that memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info&amp;#39;s pvt_info<br /> <br /> The memory for llcc_driv_data is allocated by the LLCC driver. But when<br /> it is passed as the private driver info to the EDAC core, it will get freed<br /> during the qcom_edac driver release. So when the qcom_edac driver gets probed<br /> again, it will try to use the freed data leading to the use-after-free bug.<br /> <br /> Hence, do not pass llcc_driv_data as pvt_info but rather reference it<br /> using the platform_data pointer in the qcom_edac driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix tmpfile leak<br /> <br /> Missed an error cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> trace_events_hist: add check for return value of &amp;#39;create_hist_field&amp;#39;<br /> <br /> Function &amp;#39;create_hist_field&amp;#39; is called recursively at<br /> trace_events_hist.c:1954 and can return NULL-value that&amp;#39;s why we have<br /> to check it to avoid null pointer dereference.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Make sure trace_printk() can output as soon as it can be used<br /> <br /> Currently trace_printk() can be used as soon as early_trace_init() is<br /> called from start_kernel(). But if a crash happens, and<br /> "ftrace_dump_on_oops" is set on the kernel command line, all you get will<br /> be:<br /> <br /> [ 0.456075] -0 0dN.2. 347519us : Unknown type 6<br /> [ 0.456075] -0 0dN.2. 353141us : Unknown type 6<br /> [ 0.456075] -0 0dN.2. 358684us : Unknown type 6<br /> <br /> This is because the trace_printk() event (type 6) hasn&amp;#39;t been registered<br /> yet. That gets done via an early_initcall(), which may be early, but not<br /> early enough.<br /> <br /> Instead of registering the trace_printk() event (and other ftrace events,<br /> which are not trace events) via an early_initcall(), have them registered at<br /> the same time that trace_printk() can be used. This way, if there is a<br /> crash before early_initcall(), then the trace_printk()s will actually be<br /> useful.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential memory leaks in session setup<br /> <br /> Make sure to free cifs_ses::auth_key.response before allocating it as<br /> we might end up leaking memory in reconnect or mounting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix oops due to uncleared server-&gt;smbd_conn in reconnect<br /> <br /> In smbd_destroy(), clear the server-&gt;smbd_conn pointer after freeing the<br /> smbd_connection struct that it points to so that reconnection doesn&amp;#39;t get<br /> confused.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Add sync after creating vram bo<br /> <br /> There will be data corruption on vram allocated by svm<br /> if the initialization is not complete and application is<br /> writting on the memory. Adding sync to wait for the<br /> initialization completion is to resolve this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/kprobe: Fix instruction simulation of JALR<br /> <br /> Set kprobe at &amp;#39;jalr 1140(ra)&amp;#39; of vfs_write results in the following<br /> crash:<br /> <br /> [ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170<br /> [ 32.093115] Oops [#1]<br /> [ 32.093251] Modules linked in:<br /> [ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16<br /> [ 32.093985] Hardware name: riscv-virtio,qemu (DT)<br /> [ 32.094280] epc : ksys_read+0x88/0xd6<br /> [ 32.094855] ra : ksys_read+0xc0/0xd6<br /> [ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0<br /> [ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80<br /> [ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60<br /> [ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708<br /> [ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300<br /> [ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff<br /> [ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170<br /> [ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030<br /> [ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410<br /> [ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c<br /> [ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54<br /> [ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d<br /> [ 32.098011] [] ksys_write+0x6c/0xd6<br /> [ 32.098222] [] sys_write+0x2a/0x38<br /> [ 32.098405] [] ret_from_syscall+0x0/0x2<br /> <br /> Since the rs1 and rd might be the same one, such as &amp;#39;jalr 1140(ra)&amp;#39;,<br /> hence it requires obtaining the target address from rs1 followed by<br /> updating rd.<br /> <br /> [Palmer: Pick Guo&amp;#39;s cleanup]