Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: mmci: stm32: fix DMA API overlapping mappings warning<br /> <br /> Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:<br /> <br /> DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,<br /> overlapping mappings aren&amp;#39;t supported<br /> WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568<br /> add_dma_entry+0x234/0x2f4<br /> Modules linked in:<br /> CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1<br /> Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)<br /> Workqueue: events_freezable mmc_rescan<br /> Call trace:<br /> add_dma_entry+0x234/0x2f4<br /> debug_dma_map_sg+0x198/0x350<br /> __dma_map_sg_attrs+0xa0/0x110<br /> dma_map_sg_attrs+0x10/0x2c<br /> sdmmc_idma_prep_data+0x80/0xc0<br /> mmci_prep_data+0x38/0x84<br /> mmci_start_data+0x108/0x2dc<br /> mmci_request+0xe4/0x190<br /> __mmc_start_request+0x68/0x140<br /> mmc_start_request+0x94/0xc0<br /> mmc_wait_for_req+0x70/0x100<br /> mmc_send_tuning+0x108/0x1ac<br /> sdmmc_execute_tuning+0x14c/0x210<br /> mmc_execute_tuning+0x48/0xec<br /> mmc_sd_init_uhs_card.part.0+0x208/0x464<br /> mmc_sd_init_card+0x318/0x89c<br /> mmc_attach_sd+0xe4/0x180<br /> mmc_rescan+0x244/0x320<br /> <br /> DMA API debug brings to light leaking dma-mappings as dma_map_sg and<br /> dma_unmap_sg are not correctly balanced.<br /> <br /> If an error occurs in mmci_cmd_irq function, only mmci_dma_error<br /> function is called and as this API is not managed on stm32 variant,<br /> dma_unmap_sg is never called in this error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: init irq after reg initialization<br /> <br /> Initialize the qDMA irqs after the registers are configured so that<br /> interrupts that may have been pending from a primary kernel don&amp;#39;t get<br /> processed by the irq handler before it is ready to and cause panic with<br /> the following trace:<br /> <br /> Call trace:<br /> fsl_qdma_queue_handler+0xf8/0x3e8<br /> __handle_irq_event_percpu+0x78/0x2b0<br /> handle_irq_event_percpu+0x1c/0x68<br /> handle_irq_event+0x44/0x78<br /> handle_fasteoi_irq+0xc8/0x178<br /> generic_handle_irq+0x24/0x38<br /> __handle_domain_irq+0x90/0x100<br /> gic_handle_irq+0x5c/0xb8<br /> el1_irq+0xb8/0x180<br /> _raw_spin_unlock_irqrestore+0x14/0x40<br /> __setup_irq+0x4bc/0x798<br /> request_threaded_irq+0xd8/0x190<br /> devm_request_threaded_irq+0x74/0xe8<br /> fsl_qdma_probe+0x4d4/0xca8<br /> platform_drv_probe+0x50/0xa0<br /> really_probe+0xe0/0x3f8<br /> driver_probe_device+0x64/0x130<br /> device_driver_attach+0x6c/0x78<br /> __driver_attach+0xbc/0x158<br /> bus_for_each_dev+0x5c/0x98<br /> driver_attach+0x20/0x28<br /> bus_add_driver+0x158/0x220<br /> driver_register+0x60/0x110<br /> __platform_driver_register+0x44/0x50<br /> fsl_qdma_driver_init+0x18/0x20<br /> do_one_initcall+0x48/0x258<br /> kernel_init_freeable+0x1a4/0x23c<br /> kernel_init+0x10/0xf8<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: arm64/neonbs - fix out-of-bounds access on short input<br /> <br /> The bit-sliced implementation of AES-CTR operates on blocks of 128<br /> bytes, and will fall back to the plain NEON version for tail blocks or<br /> inputs that are shorter than 128 bytes to begin with.<br /> <br /> It will call straight into the plain NEON asm helper, which performs all<br /> memory accesses in granules of 16 bytes (the size of a NEON register).<br /> For this reason, the associated plain NEON glue code will copy inputs<br /> shorter than 16 bytes into a temporary buffer, given that this is a rare<br /> occurrence and it is not worth the effort to work around this in the asm<br /> code.<br /> <br /> The fallback from the bit-sliced NEON version fails to take this into<br /> account, potentially resulting in out-of-bounds accesses. So clone the<br /> same workaround, and use a temp buffer for short in/outputs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read<br /> <br /> There is chip (ls1028a) errata:<br /> <br /> The SoC may hang on 16 byte unaligned read transactions by QDMA.<br /> <br /> Unaligned read transactions initiated by QDMA may stall in the NOC<br /> (Network On-Chip), causing a deadlock condition. Stalled transactions will<br /> trigger completion timeouts in PCIe controller.<br /> <br /> Workaround:<br /> Enable prefetch by setting the source descriptor prefetchable bit<br /> ( SD[PF] = 1 ).<br /> <br /> Implement this workaround.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: dev-replace: properly validate device names<br /> <br /> There&amp;#39;s a syzbot report that device name buffers passed to device<br /> replace are not properly checked for string termination which could lead<br /> to a read out of bounds in getname_kernel().<br /> <br /> Add a helper that validates both source and target device name buffers.<br /> For devid as the source initialize the buffer to empty string in case<br /> something tries to read it later.<br /> <br /> This was originally analyzed and fixed in a different way by Edward Adam<br /> Davis (see links).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free of anonymous device after snapshot creation failure<br /> <br /> When creating a snapshot we may do a double free of an anonymous device<br /> in case there&amp;#39;s an error committing the transaction. The second free may<br /> result in freeing an anonymous device number that was allocated by some<br /> other subsystem in the kernel or another btrfs filesystem.<br /> <br /> The steps that lead to this:<br /> <br /> 1) At ioctl.c:create_snapshot() we allocate an anonymous device number<br /> and assign it to pending_snapshot-&gt;anon_dev;<br /> <br /> 2) Then we call btrfs_commit_transaction() and end up at<br /> transaction.c:create_pending_snapshot();<br /> <br /> 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device<br /> number stored in pending_snapshot-&gt;anon_dev;<br /> <br /> 4) btrfs_get_new_fs_root() frees that anonymous device number because<br /> btrfs_lookup_fs_root() returned a root - someone else did a lookup<br /> of the new root already, which could some task doing backref walking;<br /> <br /> 5) After that some error happens in the transaction commit path, and at<br /> ioctl.c:create_snapshot() we jump to the &amp;#39;fail&amp;#39; label, and after<br /> that we free again the same anonymous device number, which in the<br /> meanwhile may have been reallocated somewhere else, because<br /> pending_snapshot-&gt;anon_dev still has the same value as in step 1.<br /> <br /> Recently syzbot ran into this and reported the following trace:<br /> <br /> ------------[ cut here ]------------<br /> ida_free called for id=51 which is not allocated.<br /> WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525<br /> Modules linked in:<br /> CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525<br /> Code: 10 42 80 3c 28 (...)<br /> RSP: 0018:ffffc90015a67300 EFLAGS: 00010246<br /> RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000<br /> RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000<br /> RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4<br /> R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246<br /> R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246<br /> FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346<br /> create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837<br /> create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931<br /> btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404<br /> create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848<br /> btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998<br /> btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044<br /> __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306<br /> btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393<br /> btrfs_ioctl+0xa74/0xd40<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:871 [inline]<br /> __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7fca3e67dda9<br /> Code: 28 00 00 00 (...)<br /> RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9<br /> RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003<br /> RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658<br /> <br /> <br /> Where we get an explicit message where we attempt to free an anonymous<br /> device number that is not currently allocated. It happens in a different<br /> code path from the example below, at btrfs_get_root_ref(), so this change<br /> may not fix the case triggered by sy<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: fix use-after-free and null-ptr-deref in gtp_newlink()<br /> <br /> The gtp_link_ops operations structure for the subsystem must be<br /> registered after registering the gtp_net_ops pernet operations structure.<br /> <br /> Syzkaller hit &amp;#39;general protection fault in gtp_genl_dump_pdp&amp;#39; bug:<br /> <br /> [ 1010.702740] gtp: GTP module unloaded<br /> [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1<br /> [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014<br /> [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00<br /> [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203<br /> [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000<br /> [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282<br /> [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000<br /> [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80<br /> [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400<br /> [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000<br /> [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0<br /> [ 1010.715968] PKRU: 55555554<br /> [ 1010.715972] Call Trace:<br /> [ 1010.715985] ? __die_body.cold+0x1a/0x1f<br /> [ 1010.715995] ? die_addr+0x43/0x70<br /> [ 1010.716002] ? exc_general_protection+0x199/0x2f0<br /> [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30<br /> [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]<br /> [ 1010.716042] __rtnl_newlink+0x1063/0x1700<br /> [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0<br /> [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0<br /> [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0<br /> [ 1010.716076] ? __kernel_text_address+0x56/0xa0<br /> [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0<br /> [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30<br /> [ 1010.716098] ? arch_stack_walk+0x9e/0xf0<br /> [ 1010.716106] ? stack_trace_save+0x91/0xd0<br /> [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170<br /> [ 1010.716121] ? __lock_acquire+0x15c5/0x5380<br /> [ 1010.716139] ? mark_held_locks+0x9e/0xe0<br /> [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0<br /> [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700<br /> [ 1010.716160] rtnl_newlink+0x69/0xa0<br /> [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50<br /> [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716179] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50<br /> [ 1010.716196] netlink_rcv_skb+0x14d/0x440<br /> [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716208] ? netlink_ack+0xab0/0xab0<br /> [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50<br /> [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50<br /> [ 1010.716226] ? __virt_addr_valid+0x30b/0x590<br /> [ 1010.716233] netlink_unicast+0x54b/0x800<br /> [ 1010.716240] ? netlink_attachskb+0x870/0x870<br /> [ 1010.716248] ? __check_object_size+0x2de/0x3b0<br /> [ 1010.716254] netlink_sendmsg+0x938/0xe40<br /> [ 1010.716261] ? netlink_unicast+0x800/0x800<br /> [ 1010.716269] ? __import_iovec+0x292/0x510<br /> [ 1010.716276] ? netlink_unicast+0x800/0x800<br /> [ 1010.716284] __sock_sendmsg+0x159/0x190<br /> [ 1010.716290] ____sys_sendmsg+0x712/0x880<br /> [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0<br /> [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270<br /> [ 1010.716309] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716315] ? drain_array_locked+0x90/0x90<br /> [ 1010.716324] ___sys_sendmsg+0xf8/0x170<br /> [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170<br /> [ 1010.716337] ? lockdep_init_map<br /> ---truncated---

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 /> riscv: Sparse-Memory/vmemmap out-of-bounds fix<br /> <br /> Offset vmemmap so that the first page of vmemmap will be mapped<br /> to the first page of physical memory in order to ensure that<br /> vmemmap’s bounds will be respected during<br /> pfn_to_page()/page_to_pfn() operations.<br /> The conversion macros will produce correct SV39/48/57 addresses<br /> for every possible/valid DRAM_BASE inside the physical memory limits.<br /> <br /> v2:Address Alex&amp;#39;s comments

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: ctr_get_width function for legacy is not defined<br /> <br /> With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n<br /> linux kernel crashes when you try perf record:<br /> <br /> $ perf record ls<br /> [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 46.750199] Oops [#1]<br /> [ 46.750342] Modules linked in:<br /> [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2<br /> [ 46.750906] Hardware name: riscv-virtio,qemu (DT)<br /> [ 46.751184] epc : 0x0<br /> [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e<br /> [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0<br /> [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0<br /> [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930<br /> [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000<br /> [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004<br /> [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2<br /> [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000<br /> [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078<br /> [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001<br /> [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff<br /> [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30<br /> [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c<br /> [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.<br /> [ 46.754939] ---[ end trace 0000000000000000 ]---<br /> [ 46.755131] note: perf-exec[107] exited with irqs disabled<br /> [ 46.755546] note: perf-exec[107] exited with preempt_count 4<br /> <br /> This happens because in the legacy case the ctr_get_width function was not<br /> defined, but it is used in arch_perf_update_userpage.<br /> <br /> Also remove extra check in riscv_pmu_ctr_get_width_mask

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Prevent potential buffer overflow in map_hw_resources<br /> <br /> Adds a check in the map_hw_resources function to prevent a potential<br /> buffer overflow. The function was accessing arrays using an index that<br /> could potentially be greater than the size of the arrays, leading to a<br /> buffer overflow.<br /> <br /> Adds a check to ensure that the index is within the bounds of the<br /> arrays. If the index is out of bounds, an error message is printed and<br /> break it will continue execution with just ignoring extra data early to<br /> prevent the buffer overflow.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow &amp;#39;dml2-&gt;v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id&amp;#39; 6 v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id&amp;#39; 6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Fix uninitialized pointer dmactl<br /> <br /> In the case where __lpass_get_dmactl_handle is called and the driver<br /> id dai_id is invalid the pointer dmactl is not being assigned a value,<br /> and dmactl contains a garbage value since it has not been initialized<br /> and so the null check may not work. Fix this to initialize dmactl to<br /> NULL. One could argue that modern compilers will set this to zero, but<br /> it is useful to keep this initialized as per the same way in functions<br /> __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.<br /> <br /> Cleans up clang scan build warning:<br /> sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition<br /> evaluates to a garbage value [core.uninitialized.Branch]