Vulnerabilities

A vulnerability was identified in GPAC up to 2.4.0. Affected is the function gf_media_export_webvtt_metadata of the file src/media_tools/media_export.c. The manipulation of the argument Name leads to null pointer dereference. The attack must be carried out locally. The exploit is publicly available and might be used. The identifier of the patch is af951b892dfbaaa38336ba2eba6d6a42c25810fd. To fix this issue, it is recommended to deploy a patch.

A vulnerability was found in Sangfor Operation and Maintenance Security Management System up to 3.0.12. This affects the function portValidate of the file /fort/ip_and_port/port_validate of the component HTTP POST Request Handler. Performing a manipulation of the argument port results in command injection. The attack can be initiated remotely. The exploit has been made public and could be used.

A flaw has been found in Beetel 777VR1 up to 01.00.09/01.00.09_55. The affected element is an unknown function of the component UART Interface. This manipulation causes improper access controls. It is feasible to perform the attack on the physical device. The complexity of an attack is rather high. The exploitability is described as difficult. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability has been found in Sangfor Operation and Maintenance Security Management System up to 3.0.12. The impacted element is an unknown function of the file /fort/audit/get_clip_img of the component HTTP POST Request Handler. Such manipulation of the argument frame/dirno leads to command injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was detected in Beetel 777VR1 up to 01.00.09/01.00.09_55. Impacted is an unknown function of the component UART Interface. The manipulation results in missing authentication. An attack on the physical device is feasible. This attack is characterized by high complexity. The exploitability is considered difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A security vulnerability has been detected in Beetel 777VR1 up to 01.00.09/01.00.09_55. This issue affects some unknown processing of the component UART Interface. The manipulation leads to improper restriction of excessive authentication attempts. It is possible to launch the attack on the physical device. The attack's complexity is rated as high. The exploitability is assessed as difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A weakness has been identified in Beetel 777VR1 up to 01.00.09/01.00.09_55. This vulnerability affects unknown code of the component UART Interface. Executing a manipulation can lead to weak password requirements. The physical device can be targeted for the attack. The attack requires a high level of complexity. It is stated that the exploitability is difficult. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

A security flaw has been discovered in Beetel 777VR1 up to 01.00.09/01.00.09_55. This affects an unknown part of the component UART Interface. Performing a manipulation results in information disclosure. The attack may be carried out on the physical device. The attack is considered to have high complexity. It is indicated that the exploitability is difficult. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: remove call_control in inactive contexts<br /> <br /> If damon_call() is executed against a DAMON context that is not running,<br /> the function returns error while keeping the damon_call_control object<br /> linked to the context&amp;#39;s call_controls list. Let&amp;#39;s suppose the object is<br /> deallocated after the damon_call(), and yet another damon_call() is<br /> executed against the same context. The function tries to add the new<br /> damon_call_control object to the call_controls list, which still has the<br /> pointer to the previous damon_call_control object, which is deallocated. <br /> As a result, use-after-free happens.<br /> <br /> This can actually be triggered using the DAMON sysfs interface. It is not<br /> easily exploitable since it requires the sysfs write permission and making<br /> a definitely weird file writes, though. Please refer to the report for<br /> more details about the issue reproduction steps.<br /> <br /> Fix the issue by making two changes. Firstly, move the final<br /> kdamond_call() for cancelling all existing damon_call() requests from<br /> terminating DAMON context to be done before the ctx-&gt;kdamond reset. This<br /> makes any code that sees NULL ctx-&gt;kdamond can safely assume the context<br /> may not access damon_call() requests anymore. Secondly, let damon_call()<br /> to cleanup the damon_call_control objects that were added to the<br /> already-terminated DAMON context, before returning the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback<br /> <br /> octep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to<br /> ioq_vector. If request_irq() fails part-way, the rollback loop calls<br /> free_irq() with dev_id set to &amp;#39;oct&amp;#39;, which does not match the original<br /> dev_id and may leave the irqaction registered.<br /> <br /> This can keep IRQ handlers alive while ioq_vector is later freed during<br /> unwind/teardown, leading to a use-after-free or crash when an interrupt<br /> fires.<br /> <br /> Fix the error path to free IRQs with the same ioq_vector dev_id used<br /> during request_irq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/buildid: use __kernel_read() for sleepable context<br /> <br /> Prevent a "BUG: unable to handle kernel NULL pointer dereference in<br /> filemap_read_folio".<br /> <br /> For the sleepable context, convert freader to use __kernel_read() instead<br /> of direct page cache access via read_cache_folio(). This simplifies the<br /> faultable code path by using the standard kernel file reading interface<br /> which handles all the complexity of reading file data.<br /> <br /> At the moment we are not changing the code for non-sleepable context which<br /> uses filemap_get_folio() and only succeeds if the target folios are<br /> already in memory and up-to-date. The reason is to keep the patch simple<br /> and easier to backport to stable kernels.<br /> <br /> Syzbot repro does not crash the kernel anymore and the selftests run<br /> successfully.<br /> <br /> In the follow up we will make __kernel_read() with IOCB_NOWAIT work for<br /> non-sleepable contexts. In addition, I would like to replace the<br /> secretmem check with a more generic approach and will add fstest for the<br /> buildid code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()<br /> <br /> Blamed commit did not take care of VLAN encapsulations<br /> as spotted by syzbot [1].<br /> <br /> Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321<br /> ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729<br /> __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860<br /> ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903<br /> gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1<br /> ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311<br /> __netif_receive_skb_one_core net/core/dev.c:6139 [inline]<br /> __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252<br /> netif_receive_skb_internal net/core/dev.c:6338 [inline]<br /> netif_receive_skb+0x57/0x630 net/core/dev.c:6397<br /> tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485<br /> tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953<br /> tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [inline]<br /> __do_sys_write fs/read_write.c:749 [inline]<br /> __se_sys_write fs/read_write.c:746 [inline]<br /> __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746<br /> x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4960 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315<br /> kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586<br /> __alloc_skb+0x805/0x1040 net/core/skbuff.c:690<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712<br /> sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995<br /> tun_alloc_skb drivers/net/tun.c:1461 [inline]<br /> tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794<br /> tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0xbe2/0x15d0 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [inline]<br /> __do_sys_write fs/read_write.c:749 [inline]<br /> __se_sys_write fs/read_write.c:746 [inline]<br /> __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746<br /> x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025