Vulnerabilities

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 /> 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 /> 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 /> block: zero non-PI portion of auto integrity buffer<br /> <br /> The auto-generated integrity buffer for writes needs to be fully<br /> initialized before being passed to the underlying block device,<br /> otherwise the uninitialized memory can be read back by userspace or<br /> anyone with physical access to the storage device. If protection<br /> information is generated, that portion of the integrity buffer is<br /> already initialized. The integrity data is also zeroed if PI generation<br /> is disabled via sysfs or the PI tuple size is 0. However, this misses<br /> the case where PI is generated and the PI tuple size is nonzero, but the<br /> metadata size is larger than the PI tuple. In this case, the remainder<br /> ("opaque") of the metadata is left uninitialized.<br /> Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the<br /> metadata is larger than just the PI tuple.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: tlv320adcx140: fix null pointer<br /> <br /> The "snd_soc_component" in "adcx140_priv" was only used once but never<br /> set. It was only used for reaching "dev" which is already present in<br /> "adcx140_priv".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1<br /> <br /> When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in<br /> response to a guest WRMSR, clear XFD-disabled features in the saved (or to<br /> be restored) XSTATE_BV to ensure KVM doesn&amp;#39;t attempt to load state for<br /> features that are disabled via the guest&amp;#39;s XFD. Because the kernel<br /> executes XRSTOR with the guest&amp;#39;s XFD, saving XSTATE_BV[i]=1 with XFD[i]=1<br /> will cause XRSTOR to #NM and panic the kernel.<br /> <br /> E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> switch_fpu_return+0x4a/0xb0<br /> kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,<br /> and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler&amp;#39;s<br /> call to fpu_update_guest_xfd().<br /> <br /> and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:exc_device_not_available+0x101/0x110<br /> Call Trace:<br /> <br /> asm_exc_device_not_available+0x1a/0x20<br /> RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90<br /> fpu_swap_kvm_fpstate+0x6b/0x120<br /> kvm_load_guest_fpu+0x30/0x80 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]<br /> kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]<br /> __x64_sys_ioctl+0x8f/0xd0<br /> do_syscall_64+0x62/0x940<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The new behavior is consistent with the AMX architecture. Per Intel&amp;#39;s SDM,<br /> XSAVE saves XSTATE_BV as &amp;#39;0&amp;#39; for components that are disabled via XFD<br /> (and non-compacted XSAVE saves the initial configuration of the state<br /> component):<br /> <br /> If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,<br /> the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;<br /> instead, it operates as if XINUSE[i] = 0 (and the state component was<br /> in its initial state): it saves bit i of XSTATE_BV field of the XSAVE<br /> header as 0; in addition, XSAVE saves the initial configuration of the<br /> state component (the other instructions do not save state component i).<br /> <br /> Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using<br /> a constant XFD based on the set of enabled features when XSAVEing for<br /> a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled<br /> features can only happen in the above interrupt case, or in similar<br /> scenarios involving preemption on preemptible kernels, because<br /> fpu_swap_kvm_fpstate()&amp;#39;s call to save_fpregs_to_fpstate() saves the<br /> outgoing FPU state with the current XFD; and that is (on all but the<br /> first WRMSR to XFD) the guest XFD.<br /> <br /> Therefore, XFD can only go out of sync with XSTATE_BV in the above<br /> interrupt case, or in similar scenarios involving preemption on<br /> preemptible kernels, and it we can consider it (de facto) part of KVM<br /> ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.<br /> <br /> [Move clea<br /> ---truncated---

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 /> ipv4: ip_gre: make ipgre_header() robust<br /> <br /> Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")<br /> <br /> Over the years, syzbot found many ways to crash the kernel<br /> in ipgre_header() [1].<br /> <br /> This involves team or bonding drivers ability to dynamically<br /> change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len<br /> <br /> In this particular crash mld_newpack() allocated an skb<br /> with a too small reserve/headroom, and by the time mld_sendpack()<br /> was called, syzbot managed to attach an ipgre device.<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0<br /> kernel BUG at net/core/skbuff.c:213 !<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213<br /> Call Trace:<br /> <br /> skb_under_panic net/core/skbuff.c:223 [inline]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897<br /> dev_hard_header include/linux/netdevice.h:3436 [inline]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: don&amp;#39;t dereference freed ring when removing sideband endpoint<br /> <br /> xhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is<br /> running and has a valid transfer ring.<br /> <br /> Lianqin reported a crash during suspend/wake-up stress testing, and<br /> found the cause to be dereferencing a non-existing transfer ring<br /> &amp;#39;ep-&gt;ring&amp;#39; during xhci_sideband_remove_endpoint().<br /> <br /> The endpoint and its ring may be in unknown state if this function<br /> is called after xHCI was reinitialized in resume (lost power), or if<br /> device is being re-enumerated, disconnected or endpoint already dropped.<br /> <br /> Fix this by both removing unnecessary ring access, and by checking<br /> ep-&gt;ring exists before dereferencing it. Also make sure endpoint is<br /> running before attempting to stop it.<br /> <br /> Remove the xhci_initialize_ring_info() call during sideband endpoint<br /> removal as is it only initializes ring structure enqueue, dequeue and<br /> cycle state values to their starting values without changing actual<br /> hardware enqueue, dequeue and cycle state. Leaving them out of sync<br /> is worse than leaving it as it is. The endpoint will get freed in after<br /> this in most usecases.<br /> <br /> If the (audio) class driver want&amp;#39;s to reuse the endpoint after offload<br /> then it is up to the class driver to ensure endpoint is properly set up.