Vulnerabilities

A heap-based buffer over-read vulnerability was found in the X.org server's ProcAppleDRICreatePixmap() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker's inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.

Improper access control vulnerability in Apaczka plugin for PrestaShop allows information gathering from saved templates without authentication.This issue affects Apaczka plugin for PrestaShop from v1 through v4.

A heap-based buffer over-read vulnerability was found in the X.org server's ProcXIGetSelectedEvents() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker's inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.

A heap-based buffer over-read vulnerability was found in the X.org server's ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker's inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.

A vulnerability was found in the quarkus-core component. Quarkus captures local environment variables from the Quarkus namespace during the application's build, therefore, running the resulting application inherits the values captured at build time. Some local environment variables may have been set by the developer or CI environment for testing purposes, such as dropping the database during application startup or trusting all TLS certificates to accept self-signed certificates. If these properties are configured using environment variables or the .env facility, they are captured into the built application, which can lead to dangerous behavior if the application does not override these values. This behavior only happens for configuration properties from the `quarkus.*` namespace. Application-specific properties are not captured.

INOTEC Sicherheitstechnik WebServer CPS220/64 3.3.19 allows a remote attacker to read arbitrary files via absolute path traversal, such as with the /cgi-bin/display?file=/etc/passwd URI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: release elements in clone only from destroy path<br /> <br /> Clone already always provides a current view of the lookup table, use it<br /> to destroy the set, otherwise it is possible to destroy elements twice.<br /> <br /> This fix requires:<br /> <br /> 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")<br /> <br /> which came after:<br /> <br /> 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").

Information exposure vulnerability in RT software affecting version 4.4.1. This vulnerability allows an attacker with local access to the device to retrieve sensitive information about the application, such as vulnerability tickets, because the application stores the information in the browser cache, leading to information exposure despite session termination.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain<br /> <br /> Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER<br /> event is reported, otherwise a stale reference to netdevice remains in<br /> the hook list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Avoid potential use-after-free in hci_error_reset<br /> <br /> While handling the HCI_EV_HARDWARE_ERROR event, if the underlying<br /> BT controller is not responding, the GPIO reset mechanism would<br /> free the hci_dev and lead to a use-after-free in hci_error_reset.<br /> <br /> Here&amp;#39;s the call trace observed on a ChromeOS device with Intel AX201:<br /> queue_work_on+0x3e/0x6c<br /> __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ]<br /> ? init_wait_entry+0x31/0x31<br /> __hci_cmd_sync+0x16/0x20 [bluetooth ]<br /> hci_error_reset+0x4f/0xa4 [bluetooth ]<br /> process_one_work+0x1d8/0x33f<br /> worker_thread+0x21b/0x373<br /> kthread+0x13a/0x152<br /> ? pr_cont_work+0x54/0x54<br /> ? kthread_blkcg+0x31/0x31<br /> ret_from_fork+0x1f/0x30<br /> <br /> This patch holds the reference count on the hci_dev while processing<br /> a HCI_EV_HARDWARE_ERROR event to avoid potential crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> stmmac: Clear variable when destroying workqueue<br /> <br /> Currently when suspending driver and stopping workqueue it is checked whether<br /> workqueue is not NULL and if so, it is destroyed.<br /> Function destroy_workqueue() does drain queue and does clear variable, but<br /> it does not set workqueue variable to NULL. This can cause kernel/module<br /> panic if code attempts to clear workqueue that was not initialized.<br /> <br /> This scenario is possible when resuming suspended driver in stmmac_resume(),<br /> because there is no handling for failed stmmac_hw_setup(),<br /> which can fail and return if DMA engine has failed to initialize,<br /> and workqueue is initialized after DMA engine.<br /> Should DMA engine fail to initialize, resume will proceed normally,<br /> but interface won&amp;#39;t work and TX queue will eventually timeout,<br /> causing &amp;#39;Reset adapter&amp;#39; error.<br /> This then does destroy workqueue during reset process.<br /> And since workqueue is initialized after DMA engine and can be skipped,<br /> it will cause kernel/module panic.<br /> <br /> To secure against this possible crash, set workqueue variable to NULL when<br /> destroying workqueue.<br /> <br /> Log/backtrace from crash goes as follows:<br /> [88.031977]------------[ cut here ]------------<br /> [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out<br /> [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398<br /> <br /> [88.032251]---[ end trace e70de432e4d5c2c0 ]---<br /> [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.<br /> [88.036359]------------[ cut here ]------------<br /> [88.036519]Call trace:<br /> [88.036523] flush_workqueue+0x3e4/0x430<br /> [88.036528] drain_workqueue+0xc4/0x160<br /> [88.036533] destroy_workqueue+0x40/0x270<br /> [88.036537] stmmac_fpe_stop_wq+0x4c/0x70<br /> [88.036541] stmmac_release+0x278/0x280<br /> [88.036546] __dev_close_many+0xcc/0x158<br /> [88.036551] dev_close_many+0xbc/0x190<br /> [88.036555] dev_close.part.0+0x70/0xc0<br /> [88.036560] dev_close+0x24/0x30<br /> [88.036564] stmmac_service_task+0x110/0x140<br /> [88.036569] process_one_work+0x1d8/0x4a0<br /> [88.036573] worker_thread+0x54/0x408<br /> [88.036578] kthread+0x164/0x170<br /> [88.036583] ret_from_fork+0x10/0x20<br /> [88.036588]---[ end trace e70de432e4d5c2c1 ]---<br /> [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: veth: clear GRO when clearing XDP even when down<br /> <br /> veth sets NETIF_F_GRO automatically when XDP is enabled,<br /> because both features use the same NAPI machinery.<br /> <br /> The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which<br /> is called both on ndo_stop and when XDP is turned off.<br /> To avoid the flag from being cleared when the device is brought<br /> down, the clearing is skipped when IFF_UP is not set.<br /> Bringing the device down should indeed not modify its features.<br /> <br /> Unfortunately, this means that clearing is also skipped when<br /> XDP is disabled _while_ the device is down. And there&amp;#39;s nothing<br /> on the open path to bring the device features back into sync.<br /> IOW if user enables XDP, disables it and then brings the device<br /> up we&amp;#39;ll end up with a stray GRO flag set but no NAPI instances.<br /> <br /> We don&amp;#39;t depend on the GRO flag on the datapath, so the datapath<br /> won&amp;#39;t crash. We will crash (or hang), however, next time features<br /> are sync&amp;#39;ed (either by user via ethtool or peer changing its config).<br /> The GRO flag will go away, and veth will try to disable the NAPIs.<br /> But the open path never created them since XDP was off, the GRO flag<br /> was a stray. If NAPI was initialized before we&amp;#39;ll hang in napi_disable().<br /> If it never was we&amp;#39;ll crash trying to stop uninitialized hrtimer.<br /> <br /> Move the GRO flag updates to the XDP enable / disable paths,<br /> instead of mixing them with the ndo_open / ndo_close paths.