Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize<br /> <br /> Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than<br /> the calculated "min" value, but greater than zero, the logic sets<br /> tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in<br /> cdc_ncm_fill_tx_frame() where all the data is handled.<br /> <br /> For small values of dwNtbOutMaxSize the memory allocated during<br /> alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to<br /> how size is aligned at alloc time:<br /> size = SKB_DATA_ALIGN(size);<br /> size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));<br /> Thus we hit the same bug that we tried to squash with<br /> commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")<br /> <br /> Low values of dwNtbOutMaxSize do not cause an issue presently because at<br /> alloc_skb() time more memory (512b) is allocated than required for the<br /> SKB headers alone (320b), leaving some space (512b - 320b = 192b)<br /> for CDC data (172b).<br /> <br /> However, if more elements (for example 3 x u64 = [24b]) were added to<br /> one of the SKB header structs, say &amp;#39;struct skb_shared_info&amp;#39;,<br /> increasing its original size (320b [320b aligned]) to something larger<br /> (344b [384b aligned]), then suddenly the CDC data (172b) no longer<br /> fits in the spare SKB data area (512b - 384b = 128b).<br /> <br /> Consequently the SKB bounds checking semantics fails and panics:<br /> <br /> skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:113!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]<br /> RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118<br /> [snip]<br /> Call Trace:<br /> <br /> skb_put+0x151/0x210 net/core/skbuff.c:2047<br /> skb_put_zero include/linux/skbuff.h:2422 [inline]<br /> cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]<br /> cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308<br /> cdc_ncm_tx_fixup+0xa3/0x100<br /> <br /> Deal with too low values of dwNtbOutMaxSize, clamp it in the range<br /> [USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure<br /> enough data space is allocated to handle CDC data by making sure<br /> dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix skb_copy_ubufs() vs BIG TCP<br /> <br /> David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy<br /> using hugepages, and skb length bigger than ~68 KB.<br /> <br /> skb_copy_ubufs() assumed it could copy all payload using up to<br /> MAX_SKB_FRAGS order-0 pages.<br /> <br /> This assumption broke when BIG TCP was able to put up to 512 KB per skb.<br /> <br /> We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45<br /> and limit gso_max_size to 180000.<br /> <br /> A solution is to use higher order pages if needed.<br /> <br /> v2: add missing __GFP_COMP, or we leak memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix deadloop issue on reading trace_pipe<br /> <br /> Soft lockup occurs when reading file &amp;#39;trace_pipe&amp;#39;:<br /> <br /> watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]<br /> [...]<br /> RIP: 0010:ring_buffer_empty_cpu+0xed/0x170<br /> RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb<br /> RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218<br /> RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f<br /> R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901<br /> R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000<br /> [...]<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> __find_next_entry+0x1a8/0x4b0<br /> ? peek_next_entry+0x250/0x250<br /> ? down_write+0xa5/0x120<br /> ? down_write_killable+0x130/0x130<br /> trace_find_next_entry_inc+0x3b/0x1d0<br /> tracing_read_pipe+0x423/0xae0<br /> ? tracing_splice_read_pipe+0xcb0/0xcb0<br /> vfs_read+0x16b/0x490<br /> ksys_read+0x105/0x210<br /> ? __ia32_sys_pwrite64+0x200/0x200<br /> ? switch_fpu_return+0x108/0x220<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> Through the vmcore, I found it&amp;#39;s because in tracing_read_pipe(),<br /> ring_buffer_empty_cpu() found some buffer is not empty but then it<br /> cannot read anything due to "rb_num_of_entries() == 0" always true,<br /> Then it infinitely loop the procedure due to user buffer not been<br /> filled, see following code path:<br /> <br /> tracing_read_pipe() {<br /> ... ...<br /> waitagain:<br /> tracing_wait_pipe() // 1. find non-empty buffer here<br /> trace_find_next_entry_inc() // 2. loop here try to find an entry<br /> __find_next_entry()<br /> ring_buffer_empty_cpu(); // 3. find non-empty buffer<br /> peek_next_entry() // 4. but peek always return NULL<br /> ring_buffer_peek()<br /> rb_buffer_peek()<br /> rb_get_reader_page()<br /> // 5. because rb_num_of_entries() == 0 always true here<br /> // then return NULL<br /> // 6. user buffer not been filled so goto &amp;#39;waitgain&amp;#39;<br /> // and eventually leads to an deadloop in kernel!!!<br /> }<br /> <br /> By some analyzing, I found that when resetting ringbuffer, the &amp;#39;entries&amp;#39;<br /> of its pages are not all cleared (see rb_reset_cpu()). Then when reducing<br /> the ringbuffer, and if some reduced pages exist dirty &amp;#39;entries&amp;#39; data, they<br /> will be added into &amp;#39;cpu_buffer-&gt;overrun&amp;#39; (see rb_remove_pages()), which<br /> cause wrong &amp;#39;overrun&amp;#39; count and eventually cause the deadloop issue.<br /> <br /> To fix it, we need to clear every pages in rb_reset_cpu().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix dev_pm_qos memleak<br /> <br /> Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to<br /> avoid following kmemleak:-<br /> <br /> blktests (master) # kmemleak-clear; ./check nvme/044;<br /> blktests (master) # kmemleak-scan ; kmemleak-show<br /> nvme/044 (Test bi-directional authentication) [passed]<br /> runtime 2.111s ... 2.124s<br /> unreferenced object 0xffff888110c46240 (size 96):<br /> comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)<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_trace+0x25/0x90<br /> [] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100<br /> [] nvme_init_ctrl+0x38e/0x410 [nvme_core]<br /> [] 0xffffffffc05e88b3<br /> [] 0xffffffffc05744cb<br /> [] vfs_write+0xc5/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Don&amp;#39;t tx before switchdev is fully configured<br /> <br /> There is possibility that ice_eswitch_port_start_xmit might be<br /> called while some resources are still not allocated which might<br /> cause NULL pointer dereference. Fix this by checking if switchdev<br /> configuration was finished.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm-qspi: return error if neither hif_mspi nor mspi is available<br /> <br /> If neither a "hif_mspi" nor "mspi" resource is present, the driver will<br /> just early exit in probe but still return success. Apart from not doing<br /> anything meaningful, this would then also lead to a null pointer access<br /> on removal, as platform_get_drvdata() would return NULL, which it would<br /> then try to dereference when trying to unregister the spi master.<br /> <br /> Fix this by unconditionally calling devm_ioremap_resource(), as it can<br /> handle a NULL res and will then return a viable ERR_PTR() if we get one.<br /> <br /> The "return 0;" was previously a "goto qspi_resource_err;" where then<br /> ret was returned, but since ret was still initialized to 0 at this place<br /> this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix<br /> use-after-free on unbind"). The issue was not introduced by this commit,<br /> only made more obvious.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix out-of-bounds when setting channels on remove<br /> <br /> If we set channels greater during iavf_remove(), and waiting reset done<br /> would be timeout, then returned with error but changed num_active_queues<br /> directly, that will lead to OOB like the following logs. Because the<br /> num_active_queues is greater than tx/rx_rings[] allocated actually.<br /> <br /> Reproducer:<br /> <br /> [root@host ~]# cat repro.sh<br /> #!/bin/bash<br /> <br /> pf_dbsf="0000:41:00.0"<br /> vf0_dbsf="0000:41:02.0"<br /> g_pids=()<br /> <br /> function do_set_numvf()<br /> {<br /> echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> }<br /> <br /> function do_set_channel()<br /> {<br /> local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)<br /> [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }<br /> ifconfig $nic 192.168.18.5 netmask 255.255.255.0<br /> ifconfig $nic up<br /> ethtool -L $nic combined 1<br /> ethtool -L $nic combined 4<br /> sleep $((RANDOM%3))<br /> }<br /> <br /> function on_exit()<br /> {<br /> local pid<br /> for pid in "${g_pids[@]}"; do<br /> kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null<br /> done<br /> g_pids=()<br /> }<br /> <br /> trap "on_exit; exit" EXIT<br /> <br /> while :; do do_set_numvf ; done &amp;<br /> g_pids+=($!)<br /> while :; do do_set_channel ; done &amp;<br /> g_pids+=($!)<br /> <br /> wait<br /> <br /> Result:<br /> <br /> [ 3506.152887] iavf 0000:41:02.0: Removing device<br /> [ 3510.400799] ==================================================================<br /> [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536<br /> [ 3510.400823]<br /> [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1<br /> [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021<br /> [ 3510.400835] Call Trace:<br /> [ 3510.400851] dump_stack+0x71/0xab<br /> [ 3510.400860] print_address_description+0x6b/0x290<br /> [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400868] kasan_report+0x14a/0x2b0<br /> [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf]<br /> [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf]<br /> [ 3510.400891] ? wait_woken+0x1d0/0x1d0<br /> [ 3510.400895] ? notifier_call_chain+0xc1/0x130<br /> [ 3510.400903] pci_device_remove+0xa8/0x1f0<br /> [ 3510.400910] device_release_driver_internal+0x1c6/0x460<br /> [ 3510.400916] pci_stop_bus_device+0x101/0x150<br /> [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420<br /> [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10<br /> [ 3510.400929] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400932] sriov_disable+0xed/0x3e0<br /> [ 3510.400936] ? bus_find_device+0x12d/0x1a0<br /> [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e]<br /> [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e]<br /> [ 3510.400968] ? pci_get_device+0x7c/0x90<br /> [ 3510.400970] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210<br /> [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]<br /> [ 3510.401001] sriov_numvfs_store+0x214/0x290<br /> [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30<br /> [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.401011] ? __check_object_size+0x15a/0x350<br /> [ 3510.401018] kernfs_fop_write+0x280/0x3f0<br /> [ 3510.401022] vfs_write+0x145/0x440<br /> [ 3510.401025] ksys_write+0xab/0x160<br /> [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0<br /> [ 3510.401031] ? fput_many+0x1a/0x120<br /> [ 3510.401032] ? filp_close+0xf0/0x130<br /> [ 3510.401038] do_syscall_64+0xa0/0x370<br /> [ 3510.401041] ? page_fault+0x8/0x30<br /> [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 3510.401073] RIP: 0033:0x7f3a9bb842c0<br /> [ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 3d <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: Don&amp;#39;t migrate perf to the CPU going to teardown<br /> <br /> The driver needs to migrate the perf context if the current using CPU going<br /> to teardown. By the time calling the cpuhp::teardown() callback the<br /> cpu_online_mask() hasn&amp;#39;t updated yet and still includes the CPU going to<br /> teardown. In current driver&amp;#39;s implementation we may migrate the context<br /> to the teardown CPU and leads to the below calltrace:<br /> <br /> ...<br /> [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008<br /> [ 368.113699][ T932] Call trace:<br /> [ 368.116834][ T932] __switch_to+0x7c/0xbc<br /> [ 368.120924][ T932] __schedule+0x338/0x6f0<br /> [ 368.125098][ T932] schedule+0x50/0xe0<br /> [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24<br /> [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc<br /> [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30<br /> [ 368.144573][ T932] mutex_lock+0x50/0x60<br /> [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0<br /> [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]<br /> [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650<br /> [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190<br /> [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0<br /> [ 368.175099][ T932] kthread+0x108/0x13c<br /> [ 368.179012][ T932] ret_from_fork+0x10/0x18<br /> ...<br /> <br /> Use function cpumask_any_but() to find one correct active cpu to fixes<br /> this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed<br /> <br /> Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel<br /> stack overflow as shown below. This issue can be reproduced by enabling<br /> CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",<br /> and then giving the following commands at the shell prompt:<br /> <br /> # cd /sys/kernel/tracing/<br /> # echo &amp;#39;p:mp1 __rcu_irq_enter_check_tick&amp;#39; &gt;&gt; kprobe_events<br /> # echo 1 &gt; events/kprobes/enable<br /> <br /> This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes<br /> blacklist using NOKPROBE_SYMBOL().<br /> <br /> Insufficient stack space to handle exception!<br /> ESR: 0x00000000f2000004 -- BRK (AArch64)<br /> FAR: 0x0000ffffccf3e510<br /> Task stack: [0xffff80000ad30000..0xffff80000ad38000]<br /> IRQ stack: [0xffff800008050000..0xffff800008058000]<br /> Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]<br /> CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __rcu_irq_enter_check_tick+0x0/0x1b8<br /> lr : ct_nmi_enter+0x11c/0x138<br /> sp : ffff80000ad30080<br /> x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000<br /> x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148<br /> x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c<br /> x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809<br /> x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000<br /> x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001<br /> x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4<br /> x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000<br /> Kernel panic - not syncing: kernel stack overflow<br /> CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0xf8/0x108<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x1c/0x38<br /> panic+0x214/0x404<br /> add_taint+0x0/0xf8<br /> panic_bad_stack+0x144/0x160<br /> handle_bad_stack+0x38/0x58<br /> __bad_stack+0x78/0x7c<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> [...]<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> el1_interrupt+0x28/0x60<br /> el1h_64_irq_handler+0x18/0x28<br /> el1h_64_irq+0x64/0x68<br /> __ftrace_set_clr_event_nolock+0x98/0x198<br /> __ftrace_set_clr_event+0x58/0x80<br /> system_enable_write+0x144/0x178<br /> vfs_write+0x174/0x738<br /> ksys_write+0xd0/0x188<br /> __arm64_sys_write+0x4c/0x60<br /> invoke_syscall+0x64/0x180<br /> el0_svc_common.constprop.0+0x84/0x160<br /> do_el0_svc+0x48/0xe8<br /> el0_svc+0x34/0xd0<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x190/0x194<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: 0x28da86000000 from 0xffff800008000000<br /> PHYS_OFFSET: 0xfffff76600000000<br /> CPU features: 0x00000,01a00100,0000421b<br /> Memory Limit: none

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}<br /> <br /> If the filename casefolding fails, we&amp;#39;ll be leaking memory from the<br /> fscrypt_name struct, namely from the &amp;#39;crypto_buf.name&amp;#39; member.<br /> <br /> Make sure we free it in the error path on both ext4_fname_setup_filename()<br /> and ext4_fname_prepare_lookup() functions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt: avoid overflow in bnxt_get_nvram_directory()<br /> <br /> The value of an arithmetic expression is subject<br /> of possible overflow due to a failure to cast operands to a larger data<br /> type before performing arithmetic. Used macro for multiplication instead<br /> operator for avoiding overflow.<br /> <br /> Found by Security Code and Linux Verification<br /> Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cpumap: Handle skb as well when clean up ptr_ring<br /> <br /> The following warning was reported when running xdp_redirect_cpu with<br /> both skb-mode and stress-mode enabled:<br /> <br /> ------------[ cut here ]------------<br /> Incorrect XDP memory type (-2128176192) usage<br /> WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405<br /> Modules linked in:<br /> CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: events __cpu_map_entry_free<br /> RIP: 0010:__xdp_return+0x1e4/0x4a0<br /> ......<br /> Call Trace:<br /> <br /> ? show_regs+0x65/0x70<br /> ? __warn+0xa5/0x240<br /> ? __xdp_return+0x1e4/0x4a0<br /> ......<br /> xdp_return_frame+0x4d/0x150<br /> __cpu_map_entry_free+0xf9/0x230<br /> process_one_work+0x6b0/0xb80<br /> worker_thread+0x96/0x720<br /> kthread+0x1a5/0x1f0<br /> ret_from_fork+0x3a/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The reason for the warning is twofold. One is due to the kthread<br /> cpu_map_kthread_run() is stopped prematurely. Another one is<br /> __cpu_map_ring_cleanup() doesn&amp;#39;t handle skb mode and treats skbs in<br /> ptr_ring as XDP frames.<br /> <br /> Prematurely-stopped kthread will be fixed by the preceding patch and<br /> ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But<br /> as the comments in __cpu_map_ring_cleanup() said, handling and freeing<br /> skbs in ptr_ring as well to "catch any broken behaviour gracefully".