Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: ring-buffer: Fix to check event length before using<br /> <br /> Check the event length before adding it for accessing next index in<br /> rb_read_data_buffer(). Since this function is used for validating<br /> possibly broken ring buffers, the length of the event could be broken.<br /> In that case, the new event (e + len) can point a wrong address.<br /> To avoid invalid memory access at boot, check whether the length of<br /> each event is in the possible range before using it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not pass flow_id to set_rps_cpu()<br /> <br /> Blamed commit made the assumption that the RPS table for each receive<br /> queue would have the same size, and that it would not change.<br /> <br /> Compute flow_id in set_rps_cpu(), do not assume we can use the value<br /> computed by get_rps_cpu(). Otherwise we risk out-of-bound access<br /> and/or crashes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-mdp: Fix error handling in probe function<br /> <br /> Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent<br /> resource leak.<br /> <br /> Add check for the return value of vpu_get_plat_device() to prevent null<br /> pointer dereference. And vpu_get_plat_device() increases the reference<br /> count of the returned platform device. Add platform_device_put() to<br /> prevent reference leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> minix: Add required sanity checking to minix_check_superblock()<br /> <br /> The fs/minix implementation of the minix filesystem does not currently<br /> support any other value for s_log_zone_size than 0. This is also the<br /> only value supported in util-linux; see mkfs.minix.c line 511. In<br /> addition, this patch adds some sanity checking for the other minix<br /> superblock fields, and moves the minix_blocks_needed() checks for the<br /> zmap and imap also to minix_check_super_block().<br /> <br /> This also closes a related syzbot bug report.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-switch: validate num_ifs to prevent out-of-bounds write<br /> <br /> The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()<br /> but never validates it against DPSW_MAX_IF (64). This value controls<br /> iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices<br /> into the fixed-size cfg-&gt;if_id[DPSW_MAX_IF] array. When firmware reports<br /> num_ifs &gt;= 64, the loop can write past the array bounds.<br /> <br /> Add a bound check for num_ifs in dpaa2_switch_init().<br /> <br /> dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port<br /> num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all<br /> ports match the flood filter, the loop fills all 64 slots and the control<br /> interface write overflows by one entry.<br /> <br /> The check uses &gt;= because num_ifs == DPSW_MAX_IF is also functionally<br /> broken.<br /> <br /> build_if_id_bitmap() silently drops any ID &gt;= 64:<br /> if (id[i]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()<br /> <br /> The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8<br /> bytes via memset without checking the buffer size parameter. This allows<br /> unprivileged userspace to trigger an out-of bounds kernel memory write<br /> by passing a small buffer, leading to potential privilege<br /> escalation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6asm: drop DSP responses for closed data streams<br /> <br /> &amp;#39;Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses<br /> after closing")&amp;#39; attempted to ignore DSP responses arriving<br /> after a stream had been closed.<br /> <br /> However, those responses were still handled, causing lockups.<br /> <br /> Fix this by unconditionally dropping all DSP responses associated with<br /> closed data streams.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: fore200e: fix use-after-free in tasklets during device removal<br /> <br /> When the PCA-200E or SBA-200E adapter is being detached, the fore200e<br /> is deallocated. However, the tx_tasklet or rx_tasklet may still be running<br /> or pending, leading to use-after-free bug when the already freed fore200e<br /> is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet().<br /> <br /> One of the race conditions can occur as follows:<br /> <br /> CPU 0 (cleanup) | CPU 1 (tasklet)<br /> fore200e_pca_remove_one() | fore200e_interrupt()<br /> fore200e_shutdown() | tasklet_schedule()<br /> kfree(fore200e) | fore200e_tx_tasklet()<br /> | fore200e-&gt; // UAF<br /> <br /> Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before<br /> the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to<br /> synchronize with any pending or running tasklets. Moreover, since<br /> fore200e_reset() could prevent further interrupts or data transfers,<br /> the tasklet_kill() should be placed after fore200e_reset() to prevent<br /> the tasklet from being rescheduled in fore200e_interrupt(). Finally,<br /> it only needs to do tasklet_kill() when the fore200e state is greater<br /> than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized<br /> in earlier states. In a word, the tasklet_kill() should be placed in<br /> the FORE200E_STATE_IRQ branch within the switch...case structure.<br /> <br /> This bug was identified through static analysis.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: vt8500lcdfb: fix missing dma_free_coherent()<br /> <br /> fbi-&gt;fb.screen_buffer is allocated with dma_alloc_coherent() but is not<br /> freed if the error path is reached.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions<br /> <br /> struct configfs_item_operations callbacks are defined like the following:<br /> <br /> int (*allow_link)(struct config_item *src, struct config_item *target);<br /> void (*drop_link)(struct config_item *src, struct config_item *target);<br /> <br /> While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify<br /> the parameters in the correct order, pci_primary_epc_epf_unlink() and<br /> pci_secondary_epc_epf_unlink() specify the parameters in the wrong order,<br /> leading to the below kernel crash when using the unlink command in<br /> configfs:<br /> <br /> Unable to handle kernel paging request at virtual address 0000000300000857<br /> Mem abort info:<br /> ...<br /> pc : string+0x54/0x14c<br /> lr : vsnprintf+0x280/0x6e8<br /> ...<br /> string+0x54/0x14c<br /> vsnprintf+0x280/0x6e8<br /> vprintk_default+0x38/0x4c<br /> vprintk+0xc4/0xe0<br /> pci_epf_unbind+0xdc/0x108<br /> configfs_unlink+0xe0/0x208+0x44/0x74<br /> vfs_unlink+0x120/0x29c<br /> __arm64_sys_unlinkat+0x3c/0x90<br /> invoke_syscall+0x48/0x134<br /> do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0<br /> <br /> [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> APEI/GHES: ARM processor Error: don&amp;#39;t go past allocated memory<br /> <br /> If the BIOS generates a very small ARM Processor Error, or<br /> an incomplete one, the current logic will fail to deferrence<br /> <br /> err-&gt;section_length<br /> and<br /> ctx_info-&gt;size<br /> <br /> Add checks to avoid that. With such changes, such GHESv2<br /> records won&amp;#39;t cause OOPSes like this:<br /> <br /> [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 1.495449] Modules linked in:<br /> [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT<br /> [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022<br /> [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred<br /> [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 1.497199] pc : log_arm_hw_error+0x5c/0x200<br /> [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220<br /> <br /> 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75).<br /> 70 err_info = (struct cper_arm_err_info *)(err + 1);<br /> 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err-&gt;err_info_num);<br /> 72 ctx_err = (u8 *)ctx_info;<br /> 73<br /> 74 for (n = 0; n context_info_num; n++) {<br /> 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info-&gt;size;<br /> 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);<br /> 77 ctx_len += sz;<br /> 78 }<br /> 79<br /> <br /> and similar ones while trying to access section_length on an<br /> error dump with too small size.<br /> <br /> [ rjw: Subject tweaks ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: consume xmit errors of GSO frames<br /> <br /> udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests<br /> currently in NIPA. They fail in the same exact way, TCP GRO<br /> test stalls occasionally and the test gets killed after 10min.<br /> <br /> These tests use veth to simulate GRO. They attach a trivial<br /> ("return XDP_PASS;") XDP program to the veth to force TSO off<br /> and NAPI on.<br /> <br /> Digging into the failure mode we can see that the connection<br /> is completely stuck after a burst of drops. The sender&amp;#39;s snd_nxt<br /> is at sequence number N [1], but the receiver claims to have<br /> received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle<br /> is that senders rtx queue is not empty (let&amp;#39;s say the block in<br /> the rtx queue is at sequence number N - 4 * MSS [3]).<br /> <br /> In this state, sender sends a retransmission from the rtx queue<br /> with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].<br /> Receiver sees it and responds with an ACK all the way up to<br /> N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA<br /> because it has no recollection of ever sending data that far out [1].<br /> And we are stuck.<br /> <br /> The root cause is the mess of the xmit return codes. veth returns<br /> an error when it can&amp;#39;t xmit a frame. We end up with a loss event<br /> like this:<br /> <br /> -------------------------------------------------<br /> | GSO super frame 1 | GSO super frame 2 |<br /> |-----------------------------------------------|<br /> | seg | seg | seg | seg | seg | seg | seg | seg |<br /> | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |<br /> -------------------------------------------------<br /> x ok ok | ok ok ok <br /> \\<br /> snd_nxt<br /> <br /> "x" means packet lost by veth, and "ok" means it went thru.<br /> Since veth has TSO disabled in this test it sees individual segments.<br /> Segment 1 is on the retransmit queue and will be resent.<br /> <br /> So why did the sender not advance snd_nxt even tho it clearly did<br /> send up to seg 8? tcp_write_xmit() interprets the return code<br /> from the core to mean that data has not been sent at all. Since<br /> TCP deals with GSO super frames, not individual segment the crux<br /> of the problem is that loss of a single segment can be interpreted<br /> as loss of all. TCP only sees the last return code for the last<br /> segment of the GSO frame (in brackets in the diagram above).<br /> <br /> Of course for the problem to occur we need a setup or a device<br /> without a Qdisc. Otherwise Qdisc layer disconnects the protocol<br /> layer from the device errors completely.<br /> <br /> We have multiple ways to fix this.<br /> <br /> 1) make veth not return an error when it lost a packet.<br /> While this is what I think we did in the past, the issue keeps<br /> reappearing and it&amp;#39;s annoying to debug. The game of whack<br /> a mole is not great.<br /> <br /> 2) fix the damn return codes<br /> We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the<br /> documentation, so maybe we should make the return code from<br /> ndo_start_xmit() a boolean. I like that the most, but perhaps<br /> some ancient, not-really-networking protocol would suffer.<br /> <br /> 3) make TCP ignore the errors<br /> It is not entirely clear to me what benefit TCP gets from<br /> interpreting the result of ip_queue_xmit()? Specifically once<br /> the connection is established and we&amp;#39;re pushing data - packet<br /> loss is just packet loss?<br /> <br /> 4) this fix<br /> Ignore the rc in the Qdisc-less+GSO case, since it&amp;#39;s unreliable.<br /> We already always return OK in the TCQ_F_CAN_BYPASS case.<br /> In the Qdisc-less case let&amp;#39;s be a bit more conservative and only<br /> mask the GSO errors. This path is taken by non-IP-"networks"<br /> like CAN, MCTP etc, so we could regress some ancient thing.<br /> This is the simplest, but also maybe the hackiest fix?<br /> <br /> Similar fix has been proposed by Eric in the past but never committed<br /> because original reporter was working with an OOT driver and wasn&amp;#39;t<br /> providing feedback (see Link).