Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: screen_info: Relocate framebuffers behind PCI bridges<br /> <br /> Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes<br /> invalid access to I/O memory.<br /> <br /> Resources behind a PCI host bridge can be relocated by a certain offset<br /> in the kernel&amp;#39;s CPU address range used for I/O. The framebuffer memory<br /> range stored in screen_info refers to the CPU addresses as seen during<br /> boot (where the offset is 0). During boot up, firmware may assign a<br /> different memory offset to the PCI host bridge and thereby relocating<br /> the framebuffer address of the PCI graphics device as seen by the kernel.<br /> The information in screen_info must be updated as well.<br /> <br /> The helper pcibios_bus_to_resource() performs the relocation of the<br /> screen_info&amp;#39;s framebuffer resource (given in PCI bus addresses). The<br /> result matches the I/O-memory resource of the PCI graphics device (given<br /> in CPU addresses). As before, we store away the information necessary to<br /> later update the information in screen_info itself.<br /> <br /> Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated<br /> EFI framebuffers") added the code for updating screen_info. It is based<br /> on similar functionality that pre-existed in efifb. Efifb uses a pointer<br /> to the PCI resource, while the newer code does a memcpy of the region.<br /> Hence efifb sees any updates to the PCI resource and avoids the issue.<br /> <br /> v3:<br /> - Only use struct pci_bus_region for PCI bus addresses (Bjorn)<br /> - Clarify address semantics in commit messages and comments (Bjorn)<br /> v2:<br /> - Fixed tags (Takashi, Ivan)<br /> - Updated information on efifb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: ep: Update read pointer only after buffer is written<br /> <br /> Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated<br /> before the buffer is written, potentially causing race conditions where<br /> the host sees an updated read pointer before the buffer is actually<br /> written. Updating rd_offset prematurely can lead to the host accessing<br /> an uninitialized or incomplete element, resulting in data corruption.<br /> <br /> Invoke the buffer write before updating rd_offset to ensure the element<br /> is fully written before signaling its availability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Add basic validation for RAS header<br /> <br /> If RAS header read from EEPROM is corrupted, it could result in trying<br /> to allocate huge memory for reading the records. Add some validation to<br /> header fields.

CNCF Harbor 2.13.x before 2.13.1 and 2.12.x before 2.12.4 allows information disclosure by administrators who can exploit an ORM Leak present in the /api/v2.0/users endpoint to leak users&amp;#39; password hash and salt values. The q URL parameter allows a user to filter users by any column, and filter password=~ could be abused to leak out a user&amp;#39;s password hash character by character. An attacker with administrator access could exploit this to leak highly sensitive information stored in the Harbor database. All endpoints that support the q URL parameter are vulnerable to this ORM leak attack.

The default configuration in ETSI Open-Source MANO (OSM) v.14.x, v.15.x, v.16.x, v.17.x does not impose any restrictions on the authentication attempts performed by the default admin user, allowing a remote attacker to escalate privileges.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: do not ping device which has failed to load firmware<br /> <br /> Syzkaller reports [1, 2] crashes caused by an attempts to ping<br /> the device which has failed to load firmware. Since such a device<br /> doesn&amp;#39;t pass &amp;#39;ieee80211_register_hw()&amp;#39;, an internal workqueue<br /> managed by &amp;#39;ieee80211_queue_work()&amp;#39; is not yet created and an<br /> attempt to queue work on it causes null-ptr-deref.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff<br /> [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: pmf: Use device managed allocations<br /> <br /> If setting up smart PC fails for any reason then this can lead to<br /> a double free when unloading amd-pmf. This is because dev-&gt;buf was<br /> freed but never set to NULL and is again freed in amd_pmf_remove().<br /> <br /> To avoid subtle allocation bugs in failures leading to a double free<br /> change all allocations into device managed allocations.

An issue in ETSI Open-Source MANO (OSM) 14.0.x before 14.0.3, 15.0.x before 15.0.2, 16.0.0, and 17.0.0 allows a remote authenticated attacker to escalate privileges via the /osm/admin/v1/users component.

A vulnerability was found in PHPGurukul Login and User Management System 3.3. It has been declared as critical. This vulnerability affects unknown code of the file /admin/yesterday-reg-users.php. The manipulation of the argument ID leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

An issue in the OTP mechanism of Chavara Family Welfare Centre Chavara Matrimony Site v2.0 allows attackers to bypass authentication via supplying a crafted request.

Apwide Golive 10.2.0 Jira plugin allows Server-Side Request Forgery (SSRF) via the test webhook function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()<br /> <br /> When rproc-&gt;state = RPROC_DETACHED and rproc_attach() is used<br /> to attach to the remote processor, if rproc_handle_resources()<br /> returns a failure, the resources allocated by imx_rproc_prepare()<br /> should be released, otherwise the following memory leak will occur.<br /> <br /> Since almost the same thing is done in imx_rproc_prepare() and<br /> rproc_resource_cleanup(), Function rproc_resource_cleanup() is able<br /> to deal with empty lists so it is better to fix the "goto" statements<br /> in rproc_attach(). replace the "unprepare_device" goto statement with<br /> "clean_up_resources" and get rid of the "unprepare_device" label.<br /> <br /> unreferenced object 0xffff0000861c5d00 (size 128):<br /> comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............<br /> backtrace:<br /> [] slab_post_alloc_hook+0x98/0x37c<br /> [] __kmem_cache_alloc_node+0x138/0x2e0<br /> [] kmalloc_trace+0x40/0x158<br /> [] rproc_mem_entry_init+0x60/0xf8<br /> [] imx_rproc_prepare+0xe0/0x180<br /> [] rproc_boot+0x2ec/0x528<br /> [] rproc_add+0x124/0x17c<br /> [] imx_rproc_probe+0x4ec/0x5d4<br /> [] platform_probe+0x68/0xd8<br /> [] really_probe+0x110/0x27c<br /> [] __driver_probe_device+0x78/0x12c<br /> [] driver_probe_device+0x3c/0x118<br /> [] __device_attach_driver+0xb8/0xf8<br /> [] bus_for_each_drv+0x84/0xe4<br /> [] __device_attach+0xfc/0x18c<br /> [] device_initial_probe+0x14/0x20