Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix 6 GHz scan construction<br /> <br /> If more than 255 colocated APs exist for the set of all<br /> APs found during 2.4/5 GHz scanning, then the 6 GHz scan<br /> construction will loop forever since the loop variable<br /> has type u8, which can never reach the number found when<br /> that&amp;#39;s bigger than 255, and is stored in a u32 variable.<br /> Also move it into the loops to have a smaller scope.<br /> <br /> Using a u32 there is fine, we limit the number of APs in<br /> the scan list and each has a limit on the number of RNR<br /> entries due to the frame size. With a limit of 1000 scan<br /> results, a frame size upper bound of 4096 (really it&amp;#39;s<br /> more like ~2300) and a TBTT entry size of at least 11,<br /> we get an upper bound for the number of ~372k, well in<br /> the bounds of a u32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data<br /> <br /> In case the non-paged data of a SKB carries protocol header and protocol<br /> payload to be transmitted on a certain platform that the DMA AXI address<br /> width is configured to 40-bit/48-bit, or the size of the non-paged data<br /> is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI<br /> address width is configured to 32-bit, then this SKB requires at least<br /> two DMA transmit descriptors to serve it.<br /> <br /> For example, three descriptors are allocated to split one DMA buffer<br /> mapped from one piece of non-paged data:<br /> dma_desc[N + 0],<br /> dma_desc[N + 1],<br /> dma_desc[N + 2].<br /> Then three elements of tx_q-&gt;tx_skbuff_dma[] will be allocated to hold<br /> extra information to be reused in stmmac_tx_clean():<br /> tx_q-&gt;tx_skbuff_dma[N + 0],<br /> tx_q-&gt;tx_skbuff_dma[N + 1],<br /> tx_q-&gt;tx_skbuff_dma[N + 2].<br /> Now we focus on tx_q-&gt;tx_skbuff_dma[entry].buf, which is the DMA buffer<br /> address returned by DMA mapping call. stmmac_tx_clean() will try to<br /> unmap the DMA buffer _ONLY_IF_ tx_q-&gt;tx_skbuff_dma[entry].buf<br /> is a valid buffer address.<br /> <br /> The expected behavior that saves DMA buffer address of this non-paged<br /> data to tx_q-&gt;tx_skbuff_dma[entry].buf is:<br /> tx_q-&gt;tx_skbuff_dma[N + 0].buf = NULL;<br /> tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;<br /> tx_q-&gt;tx_skbuff_dma[N + 2].buf = dma_map_single();<br /> Unfortunately, the current code misbehaves like this:<br /> tx_q-&gt;tx_skbuff_dma[N + 0].buf = dma_map_single();<br /> tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;<br /> tx_q-&gt;tx_skbuff_dma[N + 2].buf = NULL;<br /> <br /> On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the<br /> DMA engine, tx_q-&gt;tx_skbuff_dma[N + 0].buf is a valid buffer address<br /> obviously, then the DMA buffer will be unmapped immediately.<br /> There may be a rare case that the DMA engine does not finish the<br /> pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go<br /> horribly wrong, DMA is going to access a unmapped/unreferenced memory<br /> region, corrupted data will be transmited or iommu fault will be<br /> triggered :(<br /> <br /> In contrast, the for-loop that maps SKB fragments behaves perfectly<br /> as expected, and that is how the driver should do for both non-paged<br /> data and paged frags actually.<br /> <br /> This patch corrects DMA map/unmap sequences by fixing the array index<br /> for tx_q-&gt;tx_skbuff_dma[entry].buf when assigning DMA buffer address.<br /> <br /> Tested and verified on DWXGMAC CORE 3.20a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported<br /> <br /> acpi_evaluate_object() may return AE_NOT_FOUND (failure), which<br /> would result in dereferencing buffer.pointer (obj) while being NULL.<br /> <br /> Although this case may be unrealistic for the current code, it is<br /> still better to protect against possible bugs.<br /> <br /> Bail out also when status is AE_NOT_FOUND.<br /> <br /> This fixes 1 FORWARD_NULL issue reported by Coverity<br /> Report: CID 1600951: Null pointer dereferences (FORWARD_NULL)<br /> <br /> (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: s5p-jpeg: prevent buffer overflows<br /> <br /> The current logic allows word to be less than 2. If this happens,<br /> there will be buffer overflows, as reported by smatch. Add extra<br /> checks to prevent it.<br /> <br /> While here, remove an unused word = 0 assignment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT<br /> <br /> In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed<br /> to be either root or ingress. This assumption is bogus since it&amp;#39;s valid<br /> to create egress qdiscs with major handle ffff:<br /> Budimir Markovic found that for qdiscs like DRR that maintain an active<br /> class list, it will cause a UAF with a dangling class pointer.<br /> <br /> In 066a3b5b2346, the concern was to avoid iterating over the ingress<br /> qdisc since its parent is itself. The proper fix is to stop when parent<br /> TC_H_ROOT is reached because the only way to retrieve ingress is when a<br /> hierarchy which does not contain a ffff: major handle call into<br /> qdisc_lookup with TC_H_MAJ(TC_H_ROOT).<br /> <br /> In the scenario where major ffff: is an egress qdisc in any of the tree<br /> levels, the updates will also propagate to TC_H_ROOT, which then the<br /> iteration must stop.<br /> <br /> <br /> net/sched/sch_api.c | 2 +-<br /> 1 file changed, 1 insertion(+), 1 deletion(-)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()<br /> <br /> 1. The size of the response packet is not validated.<br /> 2. The response buffer is not freed.<br /> <br /> Resolve these issues by switching to iwl_mvm_send_cmd_status(),<br /> which handles both size validation and frees the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()<br /> <br /> This command:<br /> <br /> $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact<br /> Error: block dev insert failed: -EBUSY.<br /> <br /> fails because user space requests the same block index to be set for<br /> both ingress and egress.<br /> <br /> [ side note, I don&amp;#39;t think it even failed prior to commit 913b47d3424e<br /> ("net/sched: Introduce tc block netdev tracking infra"), because this<br /> is a command from an old set of notes of mine which used to work, but<br /> alas, I did not scientifically bisect this ]<br /> <br /> The problem is not that it fails, but rather, that the second time<br /> around, it fails differently (and irrecoverably):<br /> <br /> $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact<br /> Error: dsa_core: Flow block cb is busy.<br /> <br /> [ another note: the extack is added by me for illustration purposes.<br /> the context of the problem is that clsact_init() obtains the same<br /> &amp;q-&gt;ingress_block pointer as &amp;q-&gt;egress_block, and since we call<br /> tcf_block_get_ext() on both of them, "dev" will be added to the<br /> block-&gt;ports xarray twice, thus failing the operation: once through<br /> the ingress block pointer, and once again through the egress block<br /> pointer. the problem itself is that when xa_insert() fails, we have<br /> emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the<br /> offload never sees a corresponding FLOW_BLOCK_UNBIND. ]<br /> <br /> Even correcting the bad user input, we still cannot recover:<br /> <br /> $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact<br /> Error: dsa_core: Flow block cb is busy.<br /> <br /> Basically the only way to recover is to reboot the system, or unbind and<br /> rebind the net device driver.<br /> <br /> To fix the bug, we need to fill the correct error teardown path which<br /> was missed during code movement, and call tcf_block_offload_unbind()<br /> when xa_insert() fails.<br /> <br /> [ last note, fundamentally I blame the label naming convention in<br /> tcf_block_get_ext() for the bug. The labels should be named after what<br /> they do, not after the error path that jumps to them. This way, it is<br /> obviously wrong that two labels pointing to the same code mean<br /> something is wrong, and checking the code correctness at the goto site<br /> is also easier ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: dapm: fix bounds checker error in dapm_widget_list_create<br /> <br /> The widgets array in the snd_soc_dapm_widget_list has a __counted_by<br /> attribute attached to it, which points to the num_widgets variable. This<br /> attribute is used in bounds checking, and if it is not set before the<br /> array is filled, then the bounds sanitizer will issue a warning or a<br /> kernel panic if CONFIG_UBSAN_TRAP is set.<br /> <br /> This patch sets the size of the widgets list calculated with<br /> list_for_each as the initial value for num_widgets as it is used for<br /> allocating memory for the array. It is updated with the actual number of<br /> added elements after the array is filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: imx8ulp: correct the flexspi compatible string<br /> <br /> The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has<br /> 32 LUTs, so correct the compatible string here, otherwise will<br /> meet below error:<br /> <br /> [ 1.119072] ------------[ cut here ]------------<br /> [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.133239] Modules linked in:<br /> [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69<br /> [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT)<br /> [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64<br /> [ 1.168060] sp : ffff80008002b2a0<br /> [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000<br /> [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0<br /> [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff<br /> [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002<br /> [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00<br /> [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80<br /> [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001<br /> [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6<br /> [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92<br /> [ 1.246267] Call trace:<br /> [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.253031] spi_mem_exec_op+0x3a0/0x430<br /> [ 1.257139] spi_nor_read_id+0x80/0xcc<br /> [ 1.261065] spi_nor_scan+0x1ec/0xf10<br /> [ 1.264901] spi_nor_probe+0x108/0x2fc<br /> [ 1.268828] spi_mem_probe+0x6c/0xbc<br /> [ 1.272574] spi_probe+0x84/0xe4<br /> [ 1.275958] really_probe+0xbc/0x29c<br /> [ 1.279713] __driver_probe_device+0x78/0x12c<br /> [ 1.284277] driver_probe_device+0xd8/0x15c<br /> [ 1.288660] __device_attach_driver+0xb8/0x134<br /> [ 1.293316] bus_for_each_drv+0x88/0xe8<br /> [ 1.297337] __device_attach+0xa0/0x190<br /> [ 1.301353] device_initial_probe+0x14/0x20<br /> [ 1.305734] bus_probe_device+0xac/0xb0<br /> [ 1.309752] device_add+0x5d0/0x790<br /> [ 1.313408] __spi_add_device+0x134/0x204<br /> [ 1.317606] of_register_spi_device+0x3b4/0x590<br /> [ 1.322348] spi_register_controller+0x47c/0x754<br /> [ 1.327181] devm_spi_register_controller+0x4c/0xa4<br /> [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0<br /> [ 1.336307] platform_probe+0x68/0xc4<br /> [ 1.340145] really_probe+0xbc/0x29c<br /> [ 1.343893] __driver_probe_device+0x78/0x12c<br /> [ 1.348457] driver_probe_device+0xd8/0x15c<br /> [ 1.352838] __driver_attach+0x90/0x19c<br /> [ 1.356857] bus_for_each_dev+0x7c/0xdc<br /> [ 1.360877] driver_attach+0x24/0x30<br /> [ 1.364624] bus_add_driver+0xe4/0x208<br /> [ 1.368552] driver_register+0x5c/0x124<br /> [ 1.372573] __platform_driver_register+0x28/0x34<br /> [ 1.377497] nxp_fspi_driver_init+0x1c/0x28<br /> [ 1.381888] do_one_initcall+0x80/0x1c8<br /> [ 1.385908] kernel_init_freeable+0x1c4/0x28c<br /> [ 1.390472] kernel_init+0x20/0x1d8<br /> [ 1.394138] ret_from_fork+0x10/0x20<br /> [ 1.397885] ---[ end trace 0000000000000000 ]---<br /> [ 1.407908] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i2c: handle NULL header address<br /> <br /> daddr can be NULL if there is no neighbour table entry present,<br /> in that case the tx packet should be dropped.<br /> <br /> saddr will usually be set by MCTP core, but check for NULL in case a<br /> packet is transmitted by a different protocol.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()<br /> <br /> There are code paths from which the function is called without holding<br /> the RCU read lock, resulting in a suspicious RCU usage warning [1].<br /> <br /> Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire<br /> the RCU read lock before calling<br /> l3mdev_master_upper_ifindex_by_index_rcu().<br /> <br /> [1]<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted<br /> -----------------------------<br /> net/core/dev.c:876 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by ip/361:<br /> #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60<br /> <br /> stack backtrace:<br /> CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> lockdep_rcu_suspicious.cold+0x4f/0xd6<br /> dev_get_by_index_rcu+0x1d3/0x210<br /> l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0<br /> ip_tunnel_bind_dev+0x72f/0xa00<br /> ip_tunnel_newlink+0x368/0x7a0<br /> ipgre_newlink+0x14c/0x170<br /> __rtnl_newlink+0x1173/0x19c0<br /> rtnl_newlink+0x6c/0xa0<br /> rtnetlink_rcv_msg+0x3cc/0xf60<br /> netlink_rcv_skb+0x171/0x450<br /> netlink_unicast+0x539/0x7f0<br /> netlink_sendmsg+0x8c1/0xd80<br /> ____sys_sendmsg+0x8f9/0xc20<br /> ___sys_sendmsg+0x197/0x1e0<br /> __sys_sendmsg+0x122/0x1f0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> resource,kexec: walk_system_ram_res_rev must retain resource flags<br /> <br /> walk_system_ram_res_rev() erroneously discards resource flags when passing<br /> the information to the callback.<br /> <br /> This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have<br /> these resources selected during kexec to store kexec buffers if that<br /> memory happens to be at placed above normal system ram.<br /> <br /> This leads to undefined behavior after reboot. If the kexec buffer is<br /> never touched, nothing happens. If the kexec buffer is touched, it could<br /> lead to a crash (like below) or undefined behavior.<br /> <br /> Tested on a system with CXL memory expanders with driver managed memory,<br /> TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk&amp;#39;s showed the flags<br /> were being discarded and as a result the check for<br /> IORESOURCE_SYSRAM_DRIVER_MANAGED passes.<br /> <br /> find_next_iomem_res: name(System RAM (kmem))<br /> start(10000000000)<br /> end(1034fffffff)<br /> flags(83000200)<br /> <br /> locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0)<br /> <br /> [.] BUG: unable to handle page fault for address: ffff89834ffff000<br /> [.] #PF: supervisor read access in kernel mode<br /> [.] #PF: error_code(0x0000) - not-present page<br /> [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0<br /> [.] Oops: 0000 [#1] SMP<br /> [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0<br /> [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286<br /> [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000<br /> [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018<br /> [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900<br /> [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000<br /> [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000<br /> [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000<br /> [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [.] ata5: SATA link down (SStatus 0 SControl 300)<br /> [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0<br /> [.] PKRU: 55555554<br /> [.] Call Trace:<br /> [.] <br /> [.] ? __die+0x78/0xc0<br /> [.] ? page_fault_oops+0x2a8/0x3a0<br /> [.] ? exc_page_fault+0x84/0x130<br /> [.] ? asm_exc_page_fault+0x22/0x30<br /> [.] ? ima_restore_measurement_list+0x95/0x4b0<br /> [.] ? template_desc_init_fields+0x317/0x410<br /> [.] ? crypto_alloc_tfm_node+0x9c/0xc0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] ima_load_kexec_buffer+0x72/0xa0<br /> [.] ima_init+0x44/0xa0<br /> [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] do_one_initcall+0xad/0x200<br /> [.] ? idr_alloc_cyclic+0xaa/0x110<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? number+0x12a/0x430<br /> [.] ? sysvec_apic_timer_interrupt+0xa/0x80<br /> [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> [.] ? parse_args+0xd4/0x380<br /> [.] ? parse_args+0x14b/0x380<br /> [.] kernel_init_freeable+0x1c1/0x2b0<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] kernel_init+0x16/0x1a0<br /> [.] ret_from_fork+0x2f/0x40<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] ret_from_fork_asm+0x11/0x20<br /> [.]