Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vimc: Fix wrong function called when vimc_init() fails<br /> <br /> In vimc_init(), when platform_driver_register(&amp;vimc_pdrv) fails,<br /> platform_driver_unregister(&amp;vimc_pdrv) is wrongly called rather than<br /> platform_device_unregister(&amp;vimc_pdev), which causes kernel warning:<br /> <br /> Unexpected driver unregister!<br /> WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0<br /> RIP: 0010:driver_unregister+0x8f/0xb0<br /> Call Trace:<br /> <br /> vimc_init+0x7d/0x1000 [vimc]<br /> do_one_initcall+0xd0/0x4e0<br /> do_init_module+0x1cf/0x6b0<br /> load_module+0x65c2/0x7820

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix oops during encryption<br /> <br /> When running xfstests against Azure the following oops occurred on an<br /> arm64 system<br /> <br /> Unable to handle kernel write to read-only memory at virtual address<br /> ffff0001221cf000<br /> Mem abort info:<br /> ESR = 0x9600004f<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x0f: level 3 permission fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x0000004f<br /> CM = 0, WnR = 1<br /> swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000<br /> [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,<br /> pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787<br /> Internal error: Oops: 9600004f [#1] PREEMPT SMP<br /> ...<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)<br /> pc : __memcpy+0x40/0x230<br /> lr : scatterwalk_copychunks+0xe0/0x200<br /> sp : ffff800014e92de0<br /> x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008<br /> x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008<br /> x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000<br /> x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014<br /> x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058<br /> x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590<br /> x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580<br /> x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005<br /> x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001<br /> x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000<br /> Call trace:<br /> __memcpy+0x40/0x230<br /> scatterwalk_map_and_copy+0x98/0x100<br /> crypto_ccm_encrypt+0x150/0x180<br /> crypto_aead_encrypt+0x2c/0x40<br /> crypt_message+0x750/0x880<br /> smb3_init_transform_rq+0x298/0x340<br /> smb_send_rqst.part.11+0xd8/0x180<br /> smb_send_rqst+0x3c/0x100<br /> compound_send_recv+0x534/0xbc0<br /> smb2_query_info_compound+0x32c/0x440<br /> smb2_set_ea+0x438/0x4c0<br /> cifs_xattr_set+0x5d4/0x7c0<br /> <br /> This is because in scatterwalk_copychunks(), we attempted to write to<br /> a buffer (@sign) that was allocated in the stack (vmalloc area) by<br /> crypt_message() and thus accessing its remaining 8 (x2) bytes ended up<br /> crossing a page boundary.<br /> <br /> To simply fix it, we could just pass @sign kmalloc&amp;#39;d from<br /> crypt_message() and then we&amp;#39;re done. Luckily, we don&amp;#39;t seem to pass<br /> any other vmalloc&amp;#39;d buffers in smb_rqst::rq_iov...<br /> <br /> Instead, let&amp;#39;s map the correct pages and offsets from vmalloc buffers<br /> as well in cifs_sg_set_buf() and then avoiding such oopses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> floppy: Fix memory leak in do_floppy_init()<br /> <br /> A memory leak was reported when floppy_alloc_disk() failed in<br /> do_floppy_init().<br /> <br /> unreferenced object 0xffff888115ed25a0 (size 8):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<br /> hex dump (first 8 bytes):<br /> 00 ac 67 5b 81 88 ff ff ..g[....<br /> backtrace:<br /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180<br /> [] blk_mq_alloc_tag_set+0x573/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> unreferenced object 0xffff88810fc30540 (size 32):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<br /> hex dump (first 32 bytes):<br /> 00 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:<br /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_alloc_tag_set+0x393/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> If the floppy_alloc_disk() failed, disks of current drive will not be set,<br /> thus the lastest allocated set-&gt;tag cannot be freed in the error handling<br /> path. A simple call graph shown as below:<br /> <br /> floppy_module_init()<br /> floppy_init()<br /> do_floppy_init()<br /> for (drive = 0; drive tag allocated<br /> floppy_alloc_disk()<br /> blk_mq_alloc_disk() # error occurred, disks failed to allocated<br /> <br /> -&gt;out_put_disk:<br /> for (drive = 0; drive tag leaked<br /> <br /> Fix this problem by free the set-&gt;tag of current drive before jump to<br /> error handling path.<br /> <br /> [efremov: added stable list, changed title]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible name leaks when rio_add_device() fails<br /> <br /> Patch series "rapidio: fix three possible memory leaks".<br /> <br /> This patchset fixes three name leaks in error handling.<br /> - patch #1 fixes two name leaks while rio_add_device() fails.<br /> - patch #2 fixes a name leak while rio_register_mport() fails.<br /> <br /> <br /> This patch (of 2):<br /> <br /> If rio_add_device() returns error, the name allocated by dev_set_name()<br /> need be freed. It should use put_device() to give up the reference in the<br /> error path, so that the name can be freed in kobject_cleanup(), and the<br /> &amp;#39;rdev&amp;#39; can be freed in rio_release_dev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()<br /> <br /> syzbot is again reporting attempt to cancel uninitialized work<br /> at mgmt_index_removed() [1], for setting of HCI_MGMT flag from<br /> mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can<br /> race with testing of HCI_MGMT flag from mgmt_index_removed() from<br /> hci_sock_bind() due to lack of serialization via hci_dev_lock().<br /> <br /> Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can<br /> safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and<br /> hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag<br /> after INIT_DELAYED_WORK() completed.<br /> <br /> This is a local fix based on mgmt_chan_list_lock. Lack of serialization<br /> via hci_dev_lock() might be causing different race conditions somewhere<br /> else. But a global fix based on hci_dev_lock() should deserve a future<br /> patch.

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. In WAMR versions prior to 2.4.2, when running in LLVM-JIT mode, the runtime cannot exit normally when executing WebAssembly programs containing a memory.fill instruction where the first operand (memory address pointer) is greater than or equal to 2147483648 bytes (2GiB). This causes the runtime to hang in release builds or crash in debug builds due to accessing an invalid pointer. The issue does not occur in FAST-JIT mode or other runtime tools. This has been fixed in version 2.4.2.

In Alludo MindManager before 25.0.208 on Windows, attackers could potentially execute code as other local users on the same machine if they could write DLL files to directories within victims&amp;#39; DLL search paths.

Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2021. Notes: none.

Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2021. Notes: none.

Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2021. Notes: none.

Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2021. Notes: none.

Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2020. Notes: none.