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:
mm/damon/core: remove call_control in inactive contexts
If damon_call() is executed against a DAMON context that is not running,
the function returns error while keeping the damon_call_control object
linked to the context's call_controls list. Let's suppose the object is
deallocated after the damon_call(), and yet another damon_call() is
executed against the same context. The function tries to add the new
damon_call_control object to the call_controls list, which still has the
pointer to the previous damon_call_control object, which is deallocated.
As a result, use-after-free happens.
This can actually be triggered using the DAMON sysfs interface. It is not
easily exploitable since it requires the sysfs write permission and making
a definitely weird file writes, though. Please refer to the report for
more details about the issue reproduction steps.
Fix the issue by making two changes. Firstly, move the final
kdamond_call() for cancelling all existing damon_call() requests from
terminating DAMON context to be done before the ctx->kdamond reset. This
makes any code that sees NULL ctx->kdamond can safely assume the context
may not access damon_call() requests anymore. Secondly, let damon_call()
to cleanup the damon_call_control objects that were added to the
already-terminated DAMON context, before returning the error.
In the Linux kernel, the following vulnerability has been resolved:
net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback
octep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to
ioq_vector. If request_irq() fails part-way, the rollback loop calls
free_irq() with dev_id set to 'oct', which does not match the original
dev_id and may leave the irqaction registered.
This can keep IRQ handlers alive while ioq_vector is later freed during
unwind/teardown, leading to a use-after-free or crash when an interrupt
fires.
Fix the error path to free IRQs with the same ioq_vector dev_id used
during request_irq().
In the Linux kernel, the following vulnerability has been resolved:
lib/buildid: use __kernel_read() for sleepable context
Prevent a "BUG: unable to handle kernel NULL pointer dereference in
filemap_read_folio".
For the sleepable context, convert freader to use __kernel_read() instead
of direct page cache access via read_cache_folio(). This simplifies the
faultable code path by using the standard kernel file reading interface
which handles all the complexity of reading file data.
At the moment we are not changing the code for non-sleepable context which
uses filemap_get_folio() and only succeeds if the target folios are
already in memory and up-to-date. The reason is to keep the patch simple
and easier to backport to stable kernels.
Syzbot repro does not crash the kernel anymore and the selftests run
successfully.
In the follow up we will make __kernel_read() with IOCB_NOWAIT work for
non-sleepable contexts. In addition, I would like to replace the
secretmem check with a more generic approach and will add fstest for the
buildid code.