Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: int1092: Fix potential memory leak in sar_probe()<br /> <br /> The memory allocated for device_mode_info in parse_package() called by<br /> sar_get_data() is not freed in some of the error paths in sar_probe().<br /> Fix that by converting to use device managed allocations.

*** Pendiente de traducción *** Concrete CMS below 9.5.3 does not perform an object-level authorization check when a Page Type was updated. The Types::submit() dashboard controller loaded and saved the Page Type identified by a user-supplied ptID without calling canEditPageType(), so a signed-in dashboard user permitted to edit one Page Type could modify the configuration of Page Types outside their assigned authorization boundary. The update_page_type token was validated but is action- and user-scoped rather than object-scoped, so it did not constrain which Page Type could be targeted. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.

*** Pendiente de traducción *** Concrete CMS versions 9.5.0 through 9.5.2 are vulnerable to Open Redirect via the rcURL parameter. An attacker can craft a single link on the site&amp;#39;s own domain that sends a user to an arbitrary external site immediately after authentication, facilitating phishing and credential theft. The same handling is present in the registration flow, giving a second entry point on sites with registration enabled. Concrete CMS versions prior to 9.5.0 do not include the rcURL parameter or this allowlist and are not affected. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.3 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Michal M. for reporting.

*** Pendiente de traducción *** Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery in the Move Multiple Groups feature. The dashboard/users/groups/bulkupdate/confirm() endpoint moved the selected group tree nodes without validating an action token, so a state-changing group move could be processed for an authenticated user who did not initiate it. Because relocating a group under a new parent causes that group&amp;#39;s members to inherit the parent&amp;#39;s permissions, a forged move can change effective authorization. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails<br /> <br /> amd_pmc_probe() registers the LPS0 s2idle handler with<br /> acpi_register_lps0_dev() and creates the driver&amp;#39;s debugfs directory before<br /> calling amd_stb_s2d_init(), which is the last step in probe that can fail.<br /> <br /> When amd_stb_s2d_init() fails (for example the S2D telemetry region cannot<br /> be ioremapped on a long-running system, or the SMU rejects the S2D setup)<br /> the error path only calls pci_dev_put() and returns. This leaves<br /> amd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaks<br /> the debugfs directory, while the devm-managed resources backing the handler<br /> are torn down.<br /> <br /> Reloading the module then walks the corrupted list in<br /> acpi_register_lps0_dev() and hits:<br /> <br /> list_add corruption. next-&gt;prev should be prev, but was NULL.<br /> kernel BUG at lib/list_debug.c:29!<br /> acpi_register_lps0_dev+0x44/0x80<br /> amd_pmc_probe+0x224/0x380 [amd_pmc]<br /> platform_probe+0x67/0x90<br /> <br /> Even without a reload, the stale registration means the next s2idle<br /> transition calls into torn-down driver state.<br /> <br /> Unwind the debugfs directory and the LPS0 registration on the<br /> amd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to call<br /> unconditionally here: it is guarded on the same conditions as<br /> acpi_register_lps0_dev(), which is exactly what amd_pmc_remove() already<br /> relies on.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Propagate SMU errors and validate S2D address<br /> <br /> amd_stb_s2d_init() discards the return value of several S2D SMU commands.<br /> When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the<br /> failure is only noticed indirectly - if at all - and reported as -EIO,<br /> masking the real error.<br /> <br /> More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so<br /> on failure phys_addr_low/hi are left uninitialised and the assembled<br /> address is passed straight to devm_ioremap(). When the SMU leaves them at<br /> zero this maps physical address 0 and trips the ioremap-on-RAM warning:<br /> <br /> amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff<br /> ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff<br /> WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:...<br /> <br /> Check the return value of each SMU command and propagate it, and reject a<br /> zero physical address before calling devm_ioremap().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: stop killed, freed and out_of_sync sharing a byte<br /> <br /> The three connection state flags are single-bit bitfields, so they occupy<br /> one byte of struct smc_connection and every store to one is a<br /> read-modify-write of the other two:<br /> <br /> u8 killed : 1;<br /> u8 freed : 1;<br /> u8 out_of_sync : 1;<br /> <br /> They are not written under a common lock. smc_cdc_msg_validate() sets<br /> out_of_sync from the receive tasklet, while smc_conn_kill() sets killed<br /> from process context under lock_sock(), and the receive path does not defer<br /> to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only<br /> bh_lock_sock().<br /> <br /> Give each flag its own byte so a store no longer touches its neighbours.<br /> All readers test them as booleans and are unchanged. struct smc_connection<br /> grows by two bytes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - unmap dst before software fallback on decompress<br /> <br /> On a hardware analytics error, decompress retries through the software<br /> fallback, which writes req-&gt;dst with the CPU while it is still mapped<br /> DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the<br /> stale bounce buffer over req-&gt;dst, corrupting the result.<br /> <br /> Unmap before the fallback runs. The async path unmaps inline; the sync<br /> path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the<br /> fallback after unmapping.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot<br /> <br /> Since the hardware rfkill polling was introduced, arm64 platforms can<br /> panic with an asynchronous SError during warm reboot:<br /> <br /> SError Interrupt on CPU8, code 0x00000000be000011 -- SError<br /> Workqueue: events_power_efficient rfkill_poll [rfkill]<br /> rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]<br /> rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]<br /> rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]<br /> ieee80211_rfkill_poll+0x3c/0x70 [mac80211]<br /> cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]<br /> rfkill_poll+0x30/0x88 [rfkill]<br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> <br /> On the reboot path the kernel only runs device_shutdown(), which calls<br /> each driver&amp;#39;s .shutdown callback; .remove is not invoked. The rtw89 PCI<br /> driver had no .shutdown callback, so nothing stopped the rfkill polling<br /> work while the platform was tearing the PCIe link down. Once the link<br /> is gone, the next MMIO read from the poll handler targets a<br /> non-responding device and is reported as a fatal asynchronous SError on<br /> arm64.<br /> <br /> Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which<br /> sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB<br /> RTW89_FLAG_UNPLUGGED pattern). When the flag is set,<br /> rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the<br /> chip after shutdown begins and the SError no longer occurs.<br /> <br /> This does not call the full .remove path from .shutdown, to keep the<br /> shutdown handler minimal and avoid running the non-idempotent teardown<br /> twice.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy<br /> <br /> mt7996_mcu_get_eeprom() derives the destination of the EFUSE/EXT block<br /> copy from the address reported by the MCU response (event-&gt;addr, a<br /> device-controlled __le32) and clamps only the copy length, never the<br /> destination offset into dev-&gt;mt76.eeprom.data. A malicious or<br /> malfunctioning device can report an arbitrary address and drive an<br /> out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past<br /> eeprom.data.<br /> <br /> Reject a response whose address would place the copy outside eeprom.data<br /> before deriving the destination pointer. Devices that echo the requested<br /> in-bounds offset are unaffected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy<br /> <br /> mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver&amp;#39;s<br /> dev-&gt;mt76.eeprom.data buffer at the offset reported by the MCU response<br /> (res-&gt;addr, a device-controlled __le32) without checking it against the<br /> buffer size. A malicious or malfunctioning device can report an arbitrary<br /> address and drive a 16-byte out-of-bounds write past eeprom.data.<br /> <br /> Reject a response whose address would place the copy outside eeprom.data<br /> before deriving the destination pointer. Devices that echo the requested<br /> in-bounds offset are unaffected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in oplock break notification<br /> <br /> smb2_oplock_break_noti() reads opinfo-&gt;conn without any lock and<br /> dereferences it after two allocations which may sleep. When the<br /> durable handle owning the oplock is disconnected, session_fd_check()<br /> clears opinfo-&gt;conn and drops its conn reference under ci-&gt;m_lock, and<br /> the last ksmbd_conn_put() frees the connection. A break triggered by<br /> another connection that races with the teardown can then resurrect the<br /> freed connection: ksmbd_conn_get() is a plain atomic_inc, and the<br /> queued break work later dereferences the stale conn via<br /> ksmbd_conn_write(), a use-after-free reachable by any authenticated<br /> client holding a durable batch oplock.<br /> <br /> Thread the caller&amp;#39;s inode into the notification path instead of taking<br /> a new reference on it. Every caller of oplock_break() already holds a<br /> live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference,<br /> in the parent lease break paths) on the inode that owns the break<br /> target&amp;#39;s oplock list, so ci cannot be freed during the call, and its<br /> lock can be taken without dereferencing opinfo-&gt;o_fp, which a<br /> concurrent close may free. Select and pin the connection under<br /> ci-&gt;m_lock, the same lock session_fd_check() and<br /> ksmbd_reopen_durable_fd() use to update opinfo-&gt;conn, so a concurrent<br /> detach either loses the race to the clear or keeps the connection<br /> alive until the notification work releases it. Transfer the reference<br /> to the work item and release it on allocation failures.