Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent infinite loop in rt6_nlmsg_size()<br /> <br /> While testing prior patch, I was able to trigger<br /> an infinite loop in rt6_nlmsg_size() in the following place:<br /> <br /> list_for_each_entry_rcu(sibling, &amp;f6i-&gt;fib6_siblings,<br /> fib6_siblings) {<br /> rt6_nh_nlmsg_size(sibling-&gt;fib6_nh, &amp;nexthop_len);<br /> }<br /> <br /> This is because fib6_del_route() and fib6_add_rt2node()<br /> uses list_del_rcu(), which can confuse rcu readers,<br /> because they might no longer see the head of the list.<br /> <br /> Restart the loop if f6i-&gt;fib6_nsiblings is zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible infinite loop in fib6_info_uses_dev()<br /> <br /> fib6_info_uses_dev() seems to rely on RCU without an explicit<br /> protection.<br /> <br /> Like the prior fix in rt6_nlmsg_size(),<br /> we need to make sure fib6_del_route() or fib6_add_rt2node()<br /> have not removed the anchor from the list, or we risk an infinite loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix fp initialization for exception boundary<br /> <br /> In the ARM64 BPF JIT when prog-&gt;aux-&gt;exception_boundary is set for a BPF<br /> program, find_used_callee_regs() is not called because for a program<br /> acting as exception boundary, all callee saved registers are saved.<br /> find_used_callee_regs() sets `ctx-&gt;fp_used = true;` when it sees FP<br /> being used in any of the instructions.<br /> <br /> For programs acting as exception boundary, ctx-&gt;fp_used remains false<br /> even if frame pointer is used by the program and therefore, FP is not<br /> set-up for such programs in the prologue. This can cause the kernel to<br /> crash due to a pagefault.<br /> <br /> Fix it by setting ctx-&gt;fp_used = true for exception boundary programs as<br /> fp is always saved in such programs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neighbour: Fix null-ptr-deref in neigh_flush_dev().<br /> <br /> kernel test robot reported null-ptr-deref in neigh_flush_dev(). [0]<br /> <br /> The cited commit introduced per-netdev neighbour list and converted<br /> neigh_flush_dev() to use it instead of the global hash table.<br /> <br /> One thing we missed is that neigh_table_clear() calls neigh_ifdown()<br /> with NULL dev.<br /> <br /> Let&amp;#39;s restore the hash table iteration.<br /> <br /> Note that IPv6 module is no longer unloadable, so neigh_table_clear()<br /> is called only when IPv6 fails to initialise, which is unlikely to<br /> happen.<br /> <br /> [0]:<br /> IPv6: Attempt to unregister permanent protocol 136<br /> IPv6: Attempt to unregister permanent protocol 17<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000001a0: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000d00-0x0000000000000d07]<br /> CPU: 1 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.12.0-rc6-01246-gf7f52738637f #1<br /> Tainted: [T]=RANDSTRUCT<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570<br /> Code: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 ff 0f<br /> RSP: 0000:ffff88810026f408 EFLAGS: 00010206<br /> RAX: 00000000000001a0 RBX: 0000000000000d00 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640<br /> RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffffffffc0625250 R14: ffffffffc0631640 R15: dffffc0000000000<br /> FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 00000000000406f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __neigh_ifdown.llvm.6395807810224103582+0x44/0x390<br /> neigh_table_clear+0xb1/0x268<br /> ndisc_cleanup+0x21/0x38 [ipv6]<br /> init_module+0x2f5/0x468 [ipv6]<br /> do_one_initcall+0x1ba/0x628<br /> do_init_module+0x21a/0x530<br /> load_module+0x2550/0x2ea0<br /> __se_sys_finit_module+0x3d2/0x620<br /> __x64_sys_finit_module+0x76/0x88<br /> x64_sys_call+0x7ff/0xde8<br /> do_syscall_64+0xfb/0x1e8<br /> entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> RIP: 0033:0x7f575d6f2719<br /> Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719<br /> RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004<br /> RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00<br /> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000<br /> R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270<br /> <br /> Modules linked in: ipv6(+)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Remove skb secpath if xfrm state is not found<br /> <br /> Hardware returns a unique identifier for a decrypted packet&amp;#39;s xfrm<br /> state, this state is looked up in an xarray. However, the state might<br /> have been freed by the time of this lookup.<br /> <br /> Currently, if the state is not found, only a counter is incremented.<br /> The secpath (sp) extension on the skb is not removed, resulting in<br /> sp-&gt;len becoming 0.<br /> <br /> Subsequently, functions like __xfrm_policy_check() attempt to access<br /> fields such as xfrm_input_state(skb)-&gt;xso.type (which dereferences<br /> sp-&gt;xvec[sp-&gt;len - 1]) without first validating sp-&gt;len. This leads to<br /> a crash when dereferencing an invalid state pointer.<br /> <br /> This patch prevents the crash by explicitly removing the secpath<br /> extension from the skb if the xfrm state is not found after hardware<br /> decryption. This ensures downstream functions do not operate on a<br /> zero-length secpath.<br /> <br /> BUG: unable to handle page fault for address: ffffffff000002c8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 282e067 P4D 282e067 PUD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__xfrm_policy_check+0x61a/0xa30<br /> Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa<br /> RSP: 0018:ffff88885fb04918 EFLAGS: 00010297<br /> RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000<br /> RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353<br /> R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8<br /> R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00<br /> FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? try_to_wake_up+0x108/0x4c0<br /> ? udp4_lib_lookup2+0xbe/0x150<br /> ? udp_lib_lport_inuse+0x100/0x100<br /> ? __udp4_lib_lookup+0x2b0/0x410<br /> __xfrm_policy_check2.constprop.0+0x11e/0x130<br /> udp_queue_rcv_one_skb+0x1d/0x530<br /> udp_unicast_rcv_skb+0x76/0x90<br /> __udp4_lib_rcv+0xa64/0xe90<br /> ip_protocol_deliver_rcu+0x20/0x130<br /> ip_local_deliver_finish+0x75/0xa0<br /> ip_local_deliver+0xc1/0xd0<br /> ? ip_protocol_deliver_rcu+0x130/0x130<br /> ip_sublist_rcv+0x1f9/0x240<br /> ? ip_rcv_finish_core+0x430/0x430<br /> ip_list_rcv+0xfc/0x130<br /> __netif_receive_skb_list_core+0x181/0x1e0<br /> netif_receive_skb_list_internal+0x200/0x360<br /> ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]<br /> gro_receive_skb+0xfd/0x210<br /> mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]<br /> mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]<br /> ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]<br /> mlx5e_napi_poll+0x114/0xab0 [mlx5_core]<br /> __napi_poll+0x25/0x170<br /> net_rx_action+0x32d/0x3a0<br /> ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]<br /> ? notifier_call_chain+0x33/0xa0<br /> handle_softirqs+0xda/0x250<br /> irq_exit_rcu+0x6d/0xc0<br /> common_interrupt+0x81/0xa0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv<br /> <br /> Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use<br /> hdev-&gt;dump.head. However, dev_coredumpv can free the buffer. From<br /> dev_coredumpm_timeout documentation, which is used by dev_coredumpv:<br /> <br /> &gt; Creates a new device coredump for the given device. If a previous one hasn&amp;#39;t<br /> &gt; been read yet, the new coredump is discarded. The data lifetime is determined<br /> &gt; by the device coredump framework and when it is no longer needed the @free<br /> &gt; function will be called to free the data.<br /> <br /> If the data has not been read by the userspace yet, dev_coredumpv will<br /> discard new buffer, freeing hdev-&gt;dump.head. This leads to<br /> vmalloc-out-of-bounds error when skb_put_data tries to access<br /> hdev-&gt;dump.head.<br /> <br /> A crash report from syzbot illustrates this:<br /> <br /> ==================================================================<br /> BUG: KASAN: vmalloc-out-of-bounds in skb_put_data<br /> include/linux/skbuff.h:2752 [inline]<br /> BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240<br /> net/bluetooth/coredump.c:258<br /> Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844<br /> <br /> CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted<br /> 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 02/12/2025<br /> Workqueue: hci0 hci_devcd_timeout<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189<br /> __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105<br /> skb_put_data include/linux/skbuff.h:2752 [inline]<br /> hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258<br /> hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413<br /> process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400<br /> kthread+0x3c2/0x780 kernel/kthread.c:464<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping<br /> Memory state around the buggy address:<br /> ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> &gt;ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ==================================================================<br /> <br /> To avoid this issue, reorder dev_coredumpv to be called after<br /> skb_put_data that does not free the data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject narrower access to pointer ctx fields<br /> <br /> The following BPF program, simplified from a syzkaller repro, causes a<br /> kernel warning:<br /> <br /> r0 = *(u8 *)(r1 + 169);<br /> exit;<br /> <br /> With pointer field sk being at offset 168 in __sk_buff. This access is<br /> detected as a narrower read in bpf_skb_is_valid_access because it<br /> doesn&amp;#39;t match offsetof(struct __sk_buff, sk). It is therefore allowed<br /> and later proceeds to bpf_convert_ctx_access. Note that for the<br /> "is_narrower_load" case in the convert_ctx_accesses(), the insn-&gt;off<br /> is aligned, so the cnt may not be 0 because it matches the<br /> offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,<br /> the target_size stays 0 and the verifier errors with a kernel warning:<br /> <br /> verifier bug: error during ctx access conversion(1)<br /> <br /> This patch fixes that to return a proper "invalid bpf_context access<br /> off=X size=Y" error on the load instruction.<br /> <br /> The same issue affects multiple other fields in context structures that<br /> allow narrow access. Some other non-affected fields (for sk_msg,<br /> sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for<br /> consistency.<br /> <br /> Note this syzkaller crash was reported in the "Closes" link below, which<br /> used to be about a different bug, fixed in<br /> commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions<br /> in insn_def_regno()"). Because syzbot somehow confused the two bugs,<br /> the new crash and repro didn&amp;#39;t get reported to the mailing list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: xilinx: vcu: unregister pll_post only if registered correctly<br /> <br /> If registration of pll_post is failed, it will be set to NULL or ERR,<br /> unregistering same will fail with following call trace:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 008<br /> pc : clk_hw_unregister+0xc/0x20<br /> lr : clk_hw_unregister_fixed_factor+0x18/0x30<br /> sp : ffff800011923850<br /> ...<br /> Call trace:<br /> clk_hw_unregister+0xc/0x20<br /> clk_hw_unregister_fixed_factor+0x18/0x30<br /> xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu]<br /> xvcu_probe+0x2bc/0x53c [xlnx_vcu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix crash when rebind ccp device for ccp.ko<br /> <br /> When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding<br /> the ccp device causes the following crash:<br /> <br /> $ echo &amp;#39;0000:0a:00.2&amp;#39; &gt; /sys/bus/pci/drivers/ccp/unbind<br /> $ echo &amp;#39;0000:0a:00.2&amp;#39; &gt; /sys/bus/pci/drivers/ccp/bind<br /> <br /> [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> [ 204.978026] #PF: supervisor write access in kernel mode<br /> [ 204.979126] #PF: error_code(0x0002) - not-present page<br /> [ 204.980226] PGD 0 P4D 0<br /> [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI<br /> ...<br /> [ 204.997852] Call Trace:<br /> [ 204.999074] <br /> [ 205.000297] start_creating+0x9f/0x1c0<br /> [ 205.001533] debugfs_create_dir+0x1f/0x170<br /> [ 205.002769] ? srso_return_thunk+0x5/0x5f<br /> [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp]<br /> [ 205.005241] ccp5_init+0x8b2/0x960 [ccp]<br /> [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp]<br /> [ 205.007709] sp_init+0x5f/0x80 [ccp]<br /> [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp]<br /> [ 205.010165] ? srso_return_thunk+0x5/0x5f<br /> [ 205.011376] local_pci_probe+0x4f/0xb0<br /> [ 205.012584] pci_device_probe+0xdb/0x230<br /> [ 205.013810] really_probe+0xed/0x380<br /> [ 205.015024] __driver_probe_device+0x7e/0x160<br /> [ 205.016240] device_driver_attach+0x2f/0x60<br /> [ 205.017457] bind_store+0x7c/0xb0<br /> [ 205.018663] drv_attr_store+0x28/0x40<br /> [ 205.019868] sysfs_kf_write+0x5f/0x70<br /> [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0<br /> [ 205.022267] vfs_write+0x308/0x440<br /> [ 205.023453] ksys_write+0x6d/0xe0<br /> [ 205.024616] __x64_sys_write+0x1e/0x30<br /> [ 205.025778] x64_sys_call+0x16ba/0x2150<br /> [ 205.026942] do_syscall_64+0x56/0x1e0<br /> [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 205.029276] RIP: 0033:0x7fbc36f10104<br /> [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5<br /> <br /> This patch sets ccp_debugfs_dir to NULL after destroying it in<br /> ccp5_debugfs_destroy, allowing the directory dentry to be<br /> recreated when rebinding the ccp device.<br /> <br /> Tested on AMD Ryzen 7 1700X.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix KMSAN uninit-value in extent_info usage<br /> <br /> KMSAN reported a use of uninitialized value in `__is_extent_mergeable()`<br /> and `__is_back_mergeable()` via the read extent tree path.<br /> <br /> The root cause is that `get_read_extent_info()` only initializes three<br /> fields (`fofs`, `blk`, `len`) of `struct extent_info`, leaving the<br /> remaining fields uninitialized. This leads to undefined behavior<br /> when those fields are accessed later, especially during<br /> extent merging.<br /> <br /> Fix it by zero-initializing the `extent_info` struct before population.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: Fix pd UAF once and for all<br /> <br /> There is a race condition/UAF in padata_reorder that goes back<br /> to the initial commit. A reference count is taken at the start<br /> of the process in padata_do_parallel, and released at the end in<br /> padata_serial_worker.<br /> <br /> This reference count is (and only is) required for padata_replace<br /> to function correctly. If padata_replace is never called then<br /> there is no issue.<br /> <br /> In the function padata_reorder which serves as the core of padata,<br /> as soon as padata is added to queue-&gt;serial.list, and the associated<br /> spin lock released, that padata may be processed and the reference<br /> count on pd would go away.<br /> <br /> Fix this by getting the next padata before the squeue-&gt;serial lock<br /> is released.<br /> <br /> In order to make this possible, simplify padata_reorder by only<br /> calling it once the next padata arrives.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()<br /> <br /> When gmin_get_config_var() calls efi.get_variable() and the EFI variable<br /> is larger than the expected buffer size, two behaviors combine to create<br /> a stack buffer overflow:<br /> <br /> 1. gmin_get_config_var() does not return the proper error code when<br /> efi.get_variable() fails. It returns the stale &amp;#39;ret&amp;#39; value from<br /> earlier operations instead of indicating the EFI failure.<br /> <br /> 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates<br /> *out_len to the required buffer size but writes no data to the output<br /> buffer. However, due to bug #1, gmin_get_var_int() believes the call<br /> succeeded.<br /> <br /> The caller gmin_get_var_int() then performs:<br /> - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack<br /> - Calls gmin_get_config_var(dev, is_gmin, var, val, &amp;len) with len=64<br /> - If EFI variable is &gt;64 bytes, efi.get_variable() sets len=required_size<br /> - Due to bug #1, thinks call succeeded with len=required_size<br /> - Executes val[len] = 0, writing past end of 65-byte stack buffer<br /> <br /> This creates a stack buffer overflow when EFI variables are larger than<br /> 64 bytes. Since EFI variables can be controlled by firmware or system<br /> configuration, this could potentially be exploited for code execution.<br /> <br /> Fix the bug by returning proper error codes from gmin_get_config_var()<br /> based on EFI status instead of stale &amp;#39;ret&amp;#39; value.<br /> <br /> The gmin_get_var_int() function is called during device initialization<br /> for camera sensor configuration on Intel Bay Trail and Cherry Trail<br /> platforms using the atomisp camera stack.