Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix KASAN issue with tasklet<br /> <br /> KASAN testing revealed the following issue assocated with freeing an IRQ.<br /> <br /> [50006.466686] Call Trace:<br /> [50006.466691] <br /> [50006.489538] dump_stack+0x5c/0x80<br /> [50006.493475] print_address_description.constprop.6+0x1a/0x150<br /> [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma]<br /> [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma]<br /> [50006.511644] kasan_report.cold.11+0x7f/0x118<br /> [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma]<br /> [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma]<br /> [50006.528232] irdma_process_ceq+0xb2/0x400 [irdma]<br /> [50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]<br /> [50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma]<br /> [50006.545306] tasklet_action_common.isra.14+0x148/0x2c0<br /> [50006.551096] __do_softirq+0x1d0/0xaf8<br /> [50006.555396] irq_exit_rcu+0x219/0x260<br /> [50006.559670] irq_exit+0xa/0x20<br /> [50006.563320] smp_apic_timer_interrupt+0x1bf/0x690<br /> [50006.568645] apic_timer_interrupt+0xf/0x20<br /> [50006.573341] <br /> <br /> The issue is that a tasklet could be pending on another core racing<br /> the delete of the irq.<br /> <br /> Fix by insuring any scheduled tasklet is killed after deleting the<br /> irq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Fix a memleak in init_credit_return<br /> <br /> When dma_alloc_coherent fails to allocate dd-&gt;cr_base[i].va,<br /> init_credit_return should deallocate dd-&gt;cr_base and<br /> dd-&gt;cr_base[i] that allocated before. Or those resources<br /> would be never freed and a memleak is triggered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix memory leak in cachefiles_add_cache()<br /> <br /> The following memory leak was reported after unbinding /dev/cachefiles:<br /> <br /> ==================================================================<br /> unreferenced object 0xffff9b674176e3c0 (size 192):<br /> comm "cachefilesd2", pid 680, jiffies 4294881224<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc ea38a44b):<br /> [] kmem_cache_alloc+0x2d5/0x370<br /> [] prepare_creds+0x26/0x2e0<br /> [] cachefiles_determine_cache_security+0x1f/0x120<br /> [] cachefiles_add_cache+0x13c/0x3a0<br /> [] cachefiles_daemon_write+0x146/0x1c0<br /> [] vfs_write+0xcb/0x520<br /> [] ksys_write+0x69/0xf0<br /> [] do_syscall_64+0x72/0x140<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> ==================================================================<br /> <br /> Put the reference count of cache_cred in cachefiles_daemon_unbind() to<br /> fix the problem. And also put cache_cred in cachefiles_add_cache() error<br /> branch to avoid memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Update cpu_sibling_map when disabling nonboot CPUs<br /> <br /> Update cpu_sibling_map when disabling nonboot CPUs by defining &amp; calling<br /> clear_cpu_sibling_map(), otherwise we get such errors on SMT systems:<br /> <br /> jump label: negative count!<br /> WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100<br /> CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340<br /> pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20<br /> a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280<br /> a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001<br /> t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000<br /> t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964<br /> t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8<br /> s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040<br /> s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006<br /> ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100<br /> ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> ECFG: 00071c1c (LIE=2-4,10-12 VS=7)<br /> ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)<br /> PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)<br /> CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340<br /> Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000<br /> 90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0<br /> 900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001<br /> 0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0<br /> 0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f<br /> 6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000<br /> 900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000<br /> 0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4<br /> 0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> ...<br /> Call Trace:<br /> [] show_stack+0x48/0x1a0<br /> [] dump_stack_lvl+0x78/0xa0<br /> [] __warn+0x90/0x1a0<br /> [] report_bug+0x1b8/0x280<br /> [] do_bp+0x264/0x420<br /> [] __static_key_slow_dec_cpuslocked+0xec/0x100<br /> [] sched_cpu_deactivate+0x2fc/0x300<br /> [] cpuhp_invoke_callback+0x178/0x8a0<br /> [] cpuhp_thread_fun+0xf0/0x240<br /> [] smpboot_thread_fn+0x1dc/0x2e0<br /> [] kthread+0x140/0x160<br /> [] ret_from_kernel_thread+0xc/0xa4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd()<br /> <br /> When task_tag &gt;= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: think-lmi: Fix password opcode ordering for workstations<br /> <br /> The Lenovo workstations require the password opcode to be run before<br /> the attribute value is changed (if Admin password is enabled).<br /> <br /> Tested on some Thinkpads to confirm they are OK with this order too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: bpf attach/detach requires write permission<br /> <br /> Note that bpf attach/detach also requires CAP_NET_ADMIN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: fix memleak in iio_device_register_sysfs<br /> <br /> When iio_device_register_sysfs_group() fails, we should<br /> free iio_dev_opaque-&gt;chan_attr_group.attrs to prevent<br /> potential memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tools/rtla: Fix clang warning about mount_point var size<br /> <br /> clang is reporting this warning:<br /> <br /> $ make HOSTCC=clang CC=clang LLVM_IAS=1<br /> [...]<br /> clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions<br /> -fstack-protector-strong -fasynchronous-unwind-tables<br /> -fstack-clash-protection -Wall -Werror=format-security<br /> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS<br /> $(pkg-config --cflags libtracefs) -c -o src/utils.o src/utils.c<br /> <br /> src/utils.c:548:66: warning: &amp;#39;fscanf&amp;#39; may overflow; destination buffer in argument 3 has size 1024, but the corresponding specifier may require size 1025 [-Wfortify-source]<br /> 548 | while (fscanf(fp, "%*s %" STR(MAX_PATH) "s %99s %*s %*d %*d\n", mount_point, type) == 2) {<br /> | ^<br /> <br /> Increase mount_point variable size to MAX_PATH+1 to avoid the overflow.

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 /> hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed<br /> <br /> If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER<br /> handler cannot perform VF register successfully as the register call<br /> is received before netvsc_probe is finished. This is because we<br /> register register_netdevice_notifier() very early( even before<br /> vmbus_driver_register()).<br /> To fix this, we try to register each such matching VF( if it is visible<br /> as a netdevice) at the end of netvsc_probe.

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