Vulnerabilidades

*** Pendiente de traducción *** A vulnerability has been found in PHPGurukul Online Course Registration 3.1. Affected is an unknown function of the file /admin/semester.php. The manipulation of the argument semester leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

*** Pendiente de traducción *** A vulnerability was found in itsourcecode POS Point of Sale System 1.0. Affected by this vulnerability is an unknown functionality of the file /inventory/main/vendors/datatables/unit_testing/templates/-complex_header.php. The manipulation of the argument scripts results in cross site scripting. It is possible to launch the attack remotely. The exploit has been made public and could be used.

*** Pendiente de traducción *** The Biagiotti Core plugin for WordPress is vulnerable to Stored Cross-Site Scripting via shortcodes in versions up to, and including, 2.1.3 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

*** Pendiente de traducción *** On-Chip Debug and Test Interface With Improper Access Control and Improper Protection against Electromagnetic Fault Injection (EM-FI) in Nordic Semiconductor nRF52810 allow attacker to perform EM Fault Injection and bypass APPROTECT at runtime, requiring the least amount of modification to the hardware system possible.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: fix panic due to PSLVERR<br /> <br /> When the PSLVERR_RESP_EN parameter is set to 1, the device generates<br /> an error response if an attempt is made to read an empty RBR (Receive<br /> Buffer Register) while the FIFO is enabled.<br /> <br /> In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,<br /> UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes<br /> dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter<br /> function enables the FIFO via serial_out(p, UART_FCR, p-&gt;fcr).<br /> Execution proceeds to the serial_port_in(port, UART_RX).<br /> This satisfies the PSLVERR trigger condition.<br /> <br /> When another CPU (e.g., using printk()) is accessing the UART (UART<br /> is busy), the current CPU fails the check (value &amp; ~UART_LCR_SPAR) ==<br /> (lcr &amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter<br /> dw8250_force_idle().<br /> <br /> Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-&gt;lock<br /> to fix this issue.<br /> <br /> Panic backtrace:<br /> [ 0.442336] Oops - unknown exception [#1]<br /> [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a<br /> [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e<br /> ...<br /> [ 0.442416] console_on_rootfs+0x26/0x70

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ism: fix concurrency management in ism_cmd()<br /> <br /> The s390x ISM device data sheet clearly states that only one<br /> request-response sequence is allowable per ISM function at any point in<br /> time. Unfortunately as of today the s390/ism driver in Linux does not<br /> honor that requirement. This patch aims to rectify that.<br /> <br /> This problem was discovered based on Aliaksei&amp;#39;s bug report which states<br /> that for certain workloads the ISM functions end up entering error state<br /> (with PEC 2 as seen from the logs) after a while and as a consequence<br /> connections handled by the respective function break, and for future<br /> connection requests the ISM device is not considered -- given it is in a<br /> dysfunctional state. During further debugging PEC 3A was observed as<br /> well.<br /> <br /> A kernel message like<br /> [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a<br /> is a reliable indicator of the stated function entering error state<br /> with PEC 2. Let me also point out that a kernel message like<br /> [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery<br /> is a reliable indicator that the ISM function won&amp;#39;t be auto-recovered<br /> because the ISM driver currently lacks support for it.<br /> <br /> On a technical level, without this synchronization, commands (inputs to<br /> the FW) may be partially or fully overwritten (corrupted) by another CPU<br /> trying to issue commands on the same function. There is hard evidence that<br /> this can lead to DMB token values being used as DMB IOVAs, leading to<br /> PEC 2 PCI events indicating invalid DMA. But this is only one of the<br /> failure modes imaginable. In theory even completely losing one command<br /> and executing another one twice and then trying to interpret the outputs<br /> as if the command we intended to execute was actually executed and not<br /> the other one is also possible. Frankly, I don&amp;#39;t feel confident about<br /> providing an exhaustive list of possible consequences.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix unbuffered write error handling<br /> <br /> If all the subrequests in an unbuffered write stream fail, the subrequest<br /> collector doesn&amp;#39;t update the stream-&gt;transferred value and it retains its<br /> initial LONG_MAX value. Unfortunately, if all active streams fail, then we<br /> take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set<br /> in wreq-&gt;transferred - which is then returned from -&gt;write_iter().<br /> <br /> LONG_MAX was chosen as the initial value so that all the streams can be<br /> quickly assessed by taking the smallest value of all stream-&gt;transferred -<br /> but this only works if we&amp;#39;ve set any of them.<br /> <br /> Fix this by adding a flag to indicate whether the value in<br /> stream-&gt;transferred is valid and checking that when we integrate the<br /> values. stream-&gt;transferred can then be initialised to zero.<br /> <br /> This was found by running the generic/750 xfstest against cifs with<br /> cache=none. It splices data to the target file. Once (if) it has used up<br /> all the available scratch space, the writes start failing with ENOSPC.<br /> This causes -&gt;write_iter() to fail. However, it was returning<br /> wreq-&gt;transferred, i.e. LONG_MAX, rather than an error (because it thought<br /> the amount transferred was non-zero) and iter_file_splice_write() would<br /> then try to clean up that amount of pipe bufferage - leading to an oops<br /> when it overran. The kernel log showed:<br /> <br /> CIFS: VFS: Send error in write = -28<br /> <br /> followed by:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> <br /> with:<br /> <br /> RIP: 0010:iter_file_splice_write+0x3a4/0x520<br /> do_splice+0x197/0x4e0<br /> <br /> or:<br /> <br /> RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)<br /> iter_file_splice_write (fs/splice.c:755)<br /> <br /> Also put a warning check into splice to announce if -&gt;write_iter() returned<br /> that it had written more than it was asked to.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list<br /> <br /> In shrink_folio_list(), the hwpoisoned folio may be large folio, which<br /> can&amp;#39;t be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one()<br /> must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then<br /> retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of<br /> pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a<br /> WARN_ON_ONCE due to the page isn&amp;#39;t in swapcache.<br /> <br /> Since UCE is rare in real world, and race with reclaimation is more rare,<br /> just skipping the hwpoisoned large folio is enough. memory_failure() will<br /> handle it if the UCE is triggered again.<br /> <br /> This happens when memory reclaim for large folio races with<br /> memory_failure(), and will lead to kernel panic. The race is as<br /> follows:<br /> <br /> cpu0 cpu1<br /> shrink_folio_list memory_failure<br /> TestSetPageHWPoison<br /> unmap_poisoned_folio<br /> --&gt; trigger BUG_ON due to<br /> unmap_poisoned_folio couldn&amp;#39;t<br /> handle large folio<br /> <br /> [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: bno055: fix OOB access of hw_xlate array<br /> <br /> Fix a potential out-of-bounds array access of the hw_xlate array in<br /> bno055.c.<br /> <br /> In bno055_get_regmask(), hw_xlate was iterated over the length of the<br /> vals array instead of the length of the hw_xlate array. In the case of<br /> bno055_gyr_scale, the vals array is larger than the hw_xlate array,<br /> so this could result in an out-of-bounds access. In practice, this<br /> shouldn&amp;#39;t happen though because a match should always be found which<br /> breaks out of the for loop before it iterates beyond the end of the<br /> hw_xlate array.<br /> <br /> By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be<br /> sure we are iterating over the correct length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: Validate length in packet header before skb_put()<br /> <br /> When receiving a vsock packet in the guest, only the virtqueue buffer<br /> size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,<br /> virtio_vsock_skb_rx_put() uses the length from the packet header as the<br /> length argument to skb_put(), potentially resulting in SKB overflow if<br /> the host has gone wonky.<br /> <br /> Validate the length as advertised by the packet header before calling<br /> virtio_vsock_skb_rx_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Revise __get_user() to probe user read access<br /> <br /> Because of the way read access support is implemented, read access<br /> interruptions are only triggered at privilege levels 2 and 3. The<br /> kernel executes at privilege level 0, so __get_user() never triggers<br /> a read access interruption (code 26). Thus, it is currently possible<br /> for user code to access a read protected address via a system call.<br /> <br /> Fix this by probing read access rights at privilege level 3 (PRIV_USER)<br /> and setting __gu_err to -EFAULT (-14) if access isn&amp;#39;t allowed.<br /> <br /> Note the cmpiclr instruction does a 32-bit compare because COND macro<br /> doesn&amp;#39;t work inside asm.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP<br /> <br /> Since the CAAM on these SoCs is managed by another ARM core, called the<br /> SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which<br /> also reserves access to register page 0 suspend operations cannot touch<br /> this page.<br /> <br /> This is similar to when running OPTEE, where OPTEE will reserve page 0.<br /> <br /> Track this situation using a new state variable no_page0, reflecting if<br /> page 0 is reserved elsewhere, either by other management cores in SoC or<br /> by OPTEE.<br /> <br /> Replace the optee_en check in suspend/resume with the new check.<br /> <br /> optee_en cannot go away as it&amp;#39;s needed elsewhere to gate OPTEE specific<br /> situations.<br /> <br /> Fixes the following splat at suspend:<br /> <br /> Internal error: synchronous external abort: 0000000096000010 [#1] SMP<br /> Hardware name: Freescale i.MX8QXP ACU6C (DT)<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : readl+0x0/0x18<br /> lr : rd_reg32+0x18/0x3c<br /> sp : ffffffc08192ba20<br /> x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000<br /> x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090<br /> x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010<br /> x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5<br /> x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c<br /> x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001<br /> x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000<br /> x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002<br /> x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000<br /> x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004<br /> Call trace:<br /> readl+0x0/0x18<br /> caam_ctrl_suspend+0x30/0xdc<br /> dpm_run_callback.constprop.0+0x24/0x5c<br /> device_suspend+0x170/0x2e8<br /> dpm_suspend+0xa0/0x104<br /> dpm_suspend_start+0x48/0x50<br /> suspend_devices_and_enter+0x7c/0x45c<br /> pm_suspend+0x148/0x160<br /> state_store+0xb4/0xf8<br /> kobj_attr_store+0x14/0x24<br /> sysfs_kf_write+0x38/0x48<br /> kernfs_fop_write_iter+0xb4/0x178<br /> vfs_write+0x118/0x178<br /> ksys_write+0x6c/0xd0<br /> __arm64_sys_write+0x14/0x1c<br /> invoke_syscall.constprop.0+0x64/0xb0<br /> do_el0_svc+0x90/0xb0<br /> el0_svc+0x18/0x44<br /> el0t_64_sync_handler+0x88/0x124<br /> el0t_64_sync+0x150/0x154<br /> Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)