Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - add param check for DH<br /> <br /> Reject requests with a source buffer that is bigger than the size of the<br /> key. This is to prevent a possible integer underflow that might happen<br /> when copying the source scatterlist into a linear buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/lbr: Fix unchecked MSR access error on HSW<br /> <br /> The fuzzer triggers the below trace.<br /> <br /> [ 7763.384369] unchecked MSR access error: WRMSR to 0x689<br /> (tried to write 0x1fffffff8101349e) at rIP: 0xffffffff810704a4<br /> (native_write_msr+0x4/0x20)<br /> [ 7763.397420] Call Trace:<br /> [ 7763.399881] <br /> [ 7763.401994] intel_pmu_lbr_restore+0x9a/0x1f0<br /> [ 7763.406363] intel_pmu_lbr_sched_task+0x91/0x1c0<br /> [ 7763.410992] __perf_event_task_sched_in+0x1cd/0x240<br /> <br /> On a machine with the LBR format LBR_FORMAT_EIP_FLAGS2, when the TSX is<br /> disabled, a TSX quirk is required to access LBR from registers.<br /> The lbr_from_signext_quirk_needed() is introduced to determine whether<br /> the TSX quirk should be applied. However, the<br /> lbr_from_signext_quirk_needed() is invoked before the<br /> intel_pmu_lbr_init(), which parses the LBR format information. Without<br /> the correct LBR format information, the TSX quirk never be applied.<br /> <br /> Move the lbr_from_signext_quirk_needed() into the intel_pmu_lbr_init().<br /> Checking x86_pmu.lbr_has_tsx in the lbr_from_signext_quirk_needed() is<br /> not required anymore.<br /> <br /> Both LBR_FORMAT_EIP_FLAGS2 and LBR_FORMAT_INFO have LBR_TSX flag, but<br /> only the LBR_FORMAT_EIP_FLAGS2 requirs the quirk. Update the comments<br /> accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix memory leak in RSA<br /> <br /> When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is<br /> used, some components of the private key persist even after the TFM is<br /> released.<br /> Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()<br /> with a call to qat_rsa_clear_ctx() which frees all buffers referenced in<br /> the TFM context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t null dereference ops-&gt;destroy<br /> <br /> A KVM device cleanup happens in either of two callbacks:<br /> 1) destroy() which is called when the VM is being destroyed;<br /> 2) release() which is called when a device fd is closed.<br /> <br /> Most KVM devices use 1) but Book3s&amp;#39;s interrupt controller KVM devices<br /> (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during<br /> the machine execution. The error handling in kvm_ioctl_create_device()<br /> assumes destroy() is always defined which leads to NULL dereference as<br /> discovered by Syzkaller.<br /> <br /> This adds a checks for destroy!=NULL and adds a missing release().<br /> <br /> This is not changing kvm_destroy_devices() as devices with defined<br /> release() should have been removed from the KVM devices list by then.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers<br /> <br /> In case a IRQ based transfer times out the bcm2835_spi_handle_err()<br /> function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop<br /> dma_pending flag") the TX and RX DMA transfers are unconditionally<br /> canceled, leading to NULL pointer derefs if ctlr-&gt;dma_tx or<br /> ctlr-&gt;dma_rx are not set.<br /> <br /> Fix the NULL pointer deref by checking that ctlr-&gt;dma_tx and<br /> ctlr-&gt;dma_rx are valid pointers before accessing them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: gpio-xilinx: Fix integer overflow<br /> <br /> Current implementation is not able to configure more than 32 pins<br /> due to incorrect data type. So type casting with unsigned long<br /> to avoid it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix data-races around sysctl_tcp_max_reordering.<br /> <br /> While reading sysctl_tcp_max_reordering, it can be changed<br /> concurrently. Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix data-races around sysctl_tcp_slow_start_after_idle.<br /> <br /> While reading sysctl_tcp_slow_start_after_idle, it can be changed<br /> concurrently. Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix a data-race around sysctl_tcp_early_retrans.<br /> <br /> While reading sysctl_tcp_early_retrans, it can be changed concurrently.<br /> Thus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix uninit-value in mpol_rebind_policy()<br /> <br /> mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when<br /> pol-&gt;mode is MPOL_LOCAL. Check pol-&gt;mode before access<br /> pol-&gt;w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).<br /> <br /> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]<br /> BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368<br /> mpol_rebind_policy mm/mempolicy.c:352 [inline]<br /> mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368<br /> cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline]<br /> cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278<br /> cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515<br /> cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline]<br /> cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804<br /> __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520<br /> cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539<br /> cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852<br /> kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296<br /> call_write_iter include/linux/fs.h:2162 [inline]<br /> new_sync_write fs/read_write.c:503 [inline]<br /> vfs_write+0x1318/0x2030 fs/read_write.c:590<br /> ksys_write+0x28b/0x510 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0xdb/0x120 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:524 [inline]<br /> slab_alloc_node mm/slub.c:3251 [inline]<br /> slab_alloc mm/slub.c:3259 [inline]<br /> kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264<br /> mpol_new mm/mempolicy.c:293 [inline]<br /> do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853<br /> kernel_set_mempolicy mm/mempolicy.c:1504 [inline]<br /> __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline]<br /> __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507<br /> __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> KMSAN: uninit-value in mpol_rebind_task (2)<br /> https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc<br /> <br /> This patch seems to fix below bug too.<br /> KMSAN: uninit-value in mpol_rebind_mm (2)<br /> https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b<br /> <br /> The uninit-value is pol-&gt;w.cpuset_mems_allowed in mpol_rebind_policy().<br /> When syzkaller reproducer runs to the beginning of mpol_new(),<br /> <br /> mpol_new() mm/mempolicy.c<br /> do_mbind() mm/mempolicy.c<br /> kernel_mbind() mm/mempolicy.c<br /> <br /> `mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`<br /> is 0. Then<br /> <br /> mode = MPOL_LOCAL;<br /> ...<br /> policy-&gt;mode = mode;<br /> policy-&gt;flags = flags;<br /> <br /> will be executed. So in mpol_set_nodemask(),<br /> <br /> mpol_set_nodemask() mm/mempolicy.c<br /> do_mbind()<br /> kernel_mbind()<br /> <br /> pol-&gt;mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,<br /> which will be accessed in mpol_rebind_policy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix combination of jit blinding and pointers to bpf subprogs.<br /> <br /> The combination of jit blinding and pointers to bpf subprogs causes:<br /> [ 36.989548] BUG: unable to handle page fault for address: 0000000100000001<br /> [ 36.990342] #PF: supervisor instruction fetch in kernel mode<br /> [ 36.990968] #PF: error_code(0x0010) - not-present page<br /> [ 36.994859] RIP: 0010:0x100000001<br /> [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.<br /> [ 37.004091] Call Trace:<br /> [ 37.004351] <br /> [ 37.004576] ? bpf_loop+0x4d/0x70<br /> [ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b<br /> <br /> The jit blinding logic didn&amp;#39;t recognize that ld_imm64 with an address<br /> of bpf subprogram is a special instruction and proceeded to randomize it.<br /> By itself it wouldn&amp;#39;t have been an issue, but jit_subprogs() logic<br /> relies on two step process to JIT all subprogs and then JIT them<br /> again when addresses of all subprogs are known.<br /> Blinding process in the first JIT phase caused second JIT to miss<br /> adjustment of special ld_imm64.<br /> <br /> Fix this issue by ignoring special ld_imm64 instructions that don&amp;#39;t have<br /> user controlled constants and shouldn&amp;#39;t be blinded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: validate BOOT sectors_per_clusters<br /> <br /> When the NTFS BOOT sectors_per_clusters field is &gt; 0x80, it represents a<br /> shift value. Make sure that the shift value is not too large before using<br /> it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.<br /> <br /> This prevents negative shift values and shift values that are larger than<br /> the field size.<br /> <br /> Prevents this UBSAN error:<br /> <br /> UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16<br /> shift exponent -192 is negative