Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()<br /> <br /> "opp" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by<br /> removing the dereference to cache opp_table and dereference it directly<br /> where opp_table is used.<br /> <br /> This fixes the following smatch warning:<br /> <br /> drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable<br /> dereferenced before IS_ERR check &amp;#39;opp&amp;#39; (see line 230)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: don&amp;#39;t dereference mddev after export_rdev()<br /> <br /> Except for initial reference, mddev-&gt;kobject is referenced by<br /> rdev-&gt;kobject, and if the last rdev is freed, there is no guarantee that<br /> mddev is still valid. Hence mddev should not be used anymore after<br /> export_rdev().<br /> <br /> This problem can be triggered by following test for mdadm at very<br /> low rate:<br /> <br /> New file: mdadm/tests/23rdev-lifetime<br /> <br /> devname=${dev0##*/}<br /> devt=`cat /sys/block/$devname/dev`<br /> pid=""<br /> runtime=2<br /> <br /> clean_up_test() {<br /> pill -9 $pid<br /> echo clear &gt; /sys/block/md0/md/array_state<br /> }<br /> <br /> trap &amp;#39;clean_up_test&amp;#39; EXIT<br /> <br /> add_by_sysfs() {<br /> while true; do<br /> echo $devt &gt; /sys/block/md0/md/new_dev<br /> done<br /> }<br /> <br /> remove_by_sysfs(){<br /> while true; do<br /> echo remove &gt; /sys/block/md0/md/dev-${devname}/state<br /> done<br /> }<br /> <br /> echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"<br /> <br /> add_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> remove_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> sleep $runtime<br /> exit 0<br /> <br /> Test cmd:<br /> <br /> ./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime<br /> <br /> Test result:<br /> <br /> general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP<br /> CPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562<br /> RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]<br /> Call Trace:<br /> <br /> mddev_unlock+0x1b6/0x310 [md_mod]<br /> rdev_attr_store+0xec/0x190 [md_mod]<br /> sysfs_kf_write+0x52/0x70<br /> kernfs_fop_write_iter+0x19a/0x2a0<br /> vfs_write+0x3b5/0x770<br /> ksys_write+0x74/0x150<br /> __x64_sys_write+0x22/0x30<br /> do_syscall_64+0x40/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Fix this problem by don&amp;#39;t dereference mddev after export_rdev().

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.

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.

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.

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---

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".

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.

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.

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Add validation before accessing cgx and lmac<br /> <br /> with the addition of new MAC blocks like CN10K RPM and CN10KB<br /> RPM_USX, LMACs are noncontiguous and CGX blocks are also<br /> noncontiguous. But during RVU driver initialization, the driver<br /> is assuming they are contiguous and trying to access<br /> cgx or lmac with their id which is resulting in kernel panic.<br /> <br /> This patch fixes the issue by adding proper checks.<br /> <br /> [ 23.219150] pc : cgx_lmac_read+0x38/0x70<br /> [ 23.219154] lr : rvu_program_channels+0x3f0/0x498<br /> [ 23.223852] sp : ffff000100d6fc80<br /> [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:<br /> 000000000000005a<br /> [ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:<br /> fffffffffff0f000