Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command<br /> <br /> Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed<br /> when we receive the response.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Do not attempt to read past "commit"<br /> <br /> When iterating over the ring buffer while the ring buffer is active, the<br /> writer can corrupt the reader. There&amp;#39;s barriers to help detect this and<br /> handle it, but that code missed the case where the last event was at the<br /> very end of the page and has only 4 bytes left.<br /> <br /> The checks to detect the corruption by the writer to reads needs to see the<br /> length of the event. If the length in the first 4 bytes is zero then the<br /> length is stored in the second 4 bytes. But if the writer is in the process<br /> of updating that code, there&amp;#39;s a small window where the length in the first<br /> 4 bytes could be zero even though the length is only 4 bytes. That will<br /> cause rb_event_length() to read the next 4 bytes which could happen to be off the<br /> allocated page.<br /> <br /> To protect against this, fail immediately if the next event pointer is<br /> less than 8 bytes from the end of the commit (last byte of data), as all<br /> events must be a minimum of 8 bytes anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()<br /> <br /> Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.<br /> <br /> Getting a reference on the socket found in a lookup while<br /> holding a lock should happen before releasing the lock.<br /> <br /> nfc_llcp_sock_get_sn() has a similar problem.<br /> <br /> Finally nfc_llcp_recv_snl() needs to make sure the socket<br /> found by nfc_llcp_sock_from_sn() does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: amdtee: fix use-after-free vulnerability in amdtee_close_session<br /> <br /> There is a potential race condition in amdtee_close_session that may<br /> cause use-after-free in amdtee_open_session. For instance, if a session<br /> has refcount == 1, and one thread tries to free this session via:<br /> <br /> kref_put(&amp;sess-&gt;refcount, destroy_session);<br /> <br /> the reference count will get decremented, and the next step would be to<br /> call destroy_session(). However, if in another thread,<br /> amdtee_open_session() is called before destroy_session() has completed<br /> execution, alloc_session() may return &amp;#39;sess&amp;#39; that will be freed up<br /> later in destroy_session() leading to use-after-free in<br /> amdtee_open_session.<br /> <br /> To fix this issue, treat decrement of sess-&gt;refcount and removal of<br /> &amp;#39;sess&amp;#39; from session list in destroy_session() as a critical section, so<br /> that it is executed atomically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/alternatives: Disable KASAN in apply_alternatives()<br /> <br /> Fei has reported that KASAN triggers during apply_alternatives() on<br /> a 5-level paging machine:<br /> <br /> BUG: KASAN: out-of-bounds in rcu_is_watching()<br /> Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0<br /> ...<br /> __asan_load4()<br /> rcu_is_watching()<br /> trace_hardirqs_on()<br /> text_poke_early()<br /> apply_alternatives()<br /> ...<br /> <br /> On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)<br /> gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on<br /> __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().<br /> <br /> KASAN gets confused when apply_alternatives() patches the<br /> KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START<br /> static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.<br /> <br /> Fix it for real by disabling KASAN while the kernel is patching alternatives.<br /> <br /> [ mingo: updated the changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers<br /> <br /> The protocol converter configuration registers PCC8, PCCC, PCCD<br /> (implemented by the driver), as well as others, control protocol<br /> converters from multiple lanes (each represented as a different<br /> struct phy). So, if there are simultaneous calls to phy_set_mode_ext()<br /> to lanes sharing the same PCC register (either for the "old" or for the<br /> "new" protocol), corruption of the values programmed to hardware is<br /> possible, because lynx_28g_rmw() has no locking.<br /> <br /> Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take<br /> the global spinlock from the phy_ops :: set_mode() implementation. There<br /> are no other callers which modify PCC registers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Set all reserved memblocks on Node#0 at initialization<br /> <br /> After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()")<br /> we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled:<br /> <br /> [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18<br /> [ 0.000000] Oops[#1]:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733<br /> [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90<br /> [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0<br /> [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000<br /> [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800<br /> [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20<br /> [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000<br /> [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000<br /> [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000<br /> [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c<br /> [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c<br /> [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE)<br /> [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 0.000000] ECFG: 00070800 (LIE=11 VS=7)<br /> [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0)<br /> [ 0.000000] BADV: 0000000000002b82<br /> [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))<br /> [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00<br /> [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780<br /> [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748<br /> [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970<br /> [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000<br /> [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000<br /> [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918<br /> [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000<br /> [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c<br /> [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00<br /> [ 0.000000] ...<br /> [ 0.000000] Call Trace:<br /> [ 0.000000] [] reserve_bootmem_region+0xfc/0x21c<br /> [ 0.000000] [] memblock_free_all+0x114/0x350<br /> [ 0.000000] [] mm_core_init+0x138/0x3cc<br /> [ 0.000000] [] start_kernel+0x488/0x7a4<br /> [ 0.000000] [] kernel_entry+0xd8/0xdc<br /> [ 0.000000]<br /> [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd<br /> <br /> The reason is early memblock_reserve() in memblock_init() set node id to<br /> MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain<br /> reserve_bootmem_region() -&gt; init_reserved_page(). After memblock_init(),<br /> those late calls of memblock_reserve() operate on subregions of memblock<br /> .memory regions. As a result, these reserved regions will be set to the<br /> correct node at the first iteration of memmap_init_reserved_pages().<br /> <br /> So set all reserved memblocks on Node#0 at initialization can avoid this<br /> panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: assert requested protocol is valid<br /> <br /> The protocol is used in a bit mask to determine if the protocol is<br /> supported. Assert the provided protocol is less than the maximum<br /> defined so it doesn&amp;#39;t potentially perform a shift-out-of-bounds and<br /> provide a clearer error for undefined protocols vs unsupported ones.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()<br /> <br /> The nvme_fc_fcp_op structure describing an AEN operation is initialized with a<br /> null request structure pointer. An FC LLDD may make a call to<br /> nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.<br /> <br /> Add validation of the request structure pointer before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ravb: Fix use-after-free issue in ravb_tx_timeout_work()<br /> <br /> The ravb_stop() should call cancel_work_sync(). Otherwise,<br /> ravb_tx_timeout_work() is possible to use the freed priv after<br /> ravb_remove() was called like below:<br /> <br /> CPU0 CPU1<br /> ravb_tx_timeout()<br /> ravb_remove()<br /> unregister_netdev()<br /> free_netdev(ndev)<br /> // free priv<br /> ravb_tx_timeout_work()<br /> // use priv<br /> <br /> unregister_netdev() will call .ndo_stop() so that ravb_stop() is<br /> called. And, after phy_stop() is called, netif_carrier_off()<br /> is also called. So that .ndo_tx_timeout() will not be called<br /> after phy_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ieee802154: ca8210: Fix a potential UAF in ca8210_probe<br /> <br /> If of_clk_add_provider() fails in ca8210_register_ext_clock(),<br /> it calls clk_unregister() to release priv-&gt;clk and returns an<br /> error. However, the caller ca8210_probe() then calls ca8210_remove(),<br /> where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In<br /> this case, a use-after-free may happen in the second time we call<br /> clk_unregister().<br /> <br /> Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could<br /> be an error code on failure of clk_register_fixed_rate(). Use<br /> IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sun6i: reduce DMA RX transfer width to single byte<br /> <br /> Through empirical testing it has been determined that sometimes RX SPI<br /> transfers with DMA enabled return corrupted data. This is down to single<br /> or even multiple bytes lost during DMA transfer from SPI peripheral to<br /> memory. It seems the RX FIFO within the SPI peripheral can become<br /> confused when performing bus read accesses wider than a single byte to it<br /> during an active SPI transfer.<br /> <br /> This patch reduces the width of individual DMA read accesses to the<br /> RX FIFO to a single byte to mitigate that issue.