Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amphion: fix REVERSE_INULL issues reported by coverity<br /> <br /> null-checking of a pointor is suggested before dereferencing it

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: Add features attr to vdpa_nl_policy for nlattr length check<br /> <br /> The vdpa_nl_policy structure is used to validate the nlattr when parsing<br /> the incoming nlmsg. It will ensure the attribute being described produces<br /> a valid nlattr pointer in info-&gt;attrs before entering into each handler<br /> in vdpa_nl_ops.<br /> <br /> That is to say, the missing part in vdpa_nl_policy may lead to illegal<br /> nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.<br /> <br /> This patch adds the missing nla_policy for vdpa features attr to avoid<br /> such bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: exc3000 - properly stop timer on shutdown<br /> <br /> We need to stop the timer on driver unbind or probe failures, otherwise<br /> we get UAF/Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()<br /> <br /> If &amp;#39;mipid_detect()&amp;#39; fails, we must free &amp;#39;md&amp;#39; to avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf trace: Really free the evsel-&gt;priv area<br /> <br /> In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in<br /> evsel-&gt;priv") it only was freeing if strcmp(evsel-&gt;tp_format-&gt;system,<br /> "syscalls") returned zero, while the corresponding initialization of<br /> evsel-&gt;priv was being performed if it was _not_ zero, i.e. if the tp<br /> system wasn&amp;#39;t &amp;#39;syscalls&amp;#39;.<br /> <br /> Just stop looking for that and free it if evsel-&gt;priv was set, which<br /> should be equivalent.<br /> <br /> Also use the pre-existing evsel_trace__delete() function.<br /> <br /> This resolves these leaks, detected with:<br /> <br /> $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin<br /> <br /> =================================================================<br /> ==481565==ERROR: LeakSanitizer: detected memory leaks<br /> <br /> Direct leak of 40 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)<br /> #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)<br /> #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307<br /> #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333<br /> #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458<br /> #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480<br /> #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212<br /> #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891<br /> #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156<br /> #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323<br /> #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377<br /> #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421<br /> #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537<br /> #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)<br /> <br /> Direct leak of 40 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)<br /> #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)<br /> #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307<br /> #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333<br /> #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458<br /> #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480<br /> #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205<br /> #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891<br /> #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156<br /> #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323<br /> #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377<br /> #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421<br /> #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537<br /> #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)<br /> <br /> SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).<br /> [root@quaco ~]#<br /> <br /> With this we plug all leaks with "perf trace sleep 1".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer<br /> <br /> smatch error:<br /> sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:<br /> we previously assumed &amp;#39;rac97&amp;#39; could be null (see line 2072)<br /> <br /> remove redundant assignment, return error if rac97 is NULL.