ISHACK AI BOT

Debian: CVE-2023-45361: mediawiki -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 10/11/2024 Description An issue was discovered in VectorComponentUserLinks.php in the Vector Skin component in MediaWiki before 1.39.5 and 1.40.x before 1.40.1. vector-intro-page MalformedTitleException is uncaught if it is not a valid title, leading to incorrect web pages. Solution(s) debian-upgrade-mediawiki References https://attackerkb.com/topics/cve-2023-45361 CVE - 2023-45361

Debian: CVE-2024-42105: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/03/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42105 CVE - 2024-42105 DSA-5747-1

Debian: CVE-2024-42127: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/03/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42127 CVE - 2024-42127 DSA-5747-1

Debian: CVE-2024-42130: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/03/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfc/nci: Add the inconsistency check between the input data length and count write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42130 CVE - 2024-42130 DLA-4008-1

Debian: CVE-2024-42102: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" Patch series "mm: Avoid possible overflows in dirty throttling". Dirty throttling logic assumes dirty limits in page units fit into 32-bits.This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways.Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this).Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs.We have div64_ul() in case we want to be safe & cheap.Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42102 CVE - 2024-42102 DSA-5747-1

Debian: CVE-2024-42104: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42104 CVE - 2024-42104 DSA-5747-1

VMware Photon OS: CVE-2024-42120 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check pipe offset before setting vblank pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array. This fixes an OVERRUN issue reported by Coverity. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-42120 CVE - 2024-42120

Debian: CVE-2015-0842: yubiserver -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description SQL injection issues (potential auth bypass) Solution(s) debian-upgrade-yubiserver References https://attackerkb.com/topics/cve-2015-0842 CVE - 2015-0842

Debian: CVE-2024-41011: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case.The GPU has an unused 4K area of the register BAR space into which you can remap registers.We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM.However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-41011 CVE - 2024-41011 DLA-3912-1

Debian: CVE-2024-42137: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42137 CVE - 2024-42137 DSA-5747-1

Debian: CVE-2024-42138: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn't reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42138 CVE - 2024-42138 DLA-4008-1

Debian: CVE-2024-42142: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-switch, Create ingress ACL when needed Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \ value false cmode runtime If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation. Fix it by creating ingress acl when needed. If esw_port_metadata is true, ingress acl exists, then create drop rule using existing ingress acl. If esw_port_metadata is false, create ingress acl and then create drop rule. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42142 CVE - 2024-42142 DLA-4008-1

Debian: CVE-2024-42140: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: riscv: kexec: Avoid deadlock in kexec crash path If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function. Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42140 CVE - 2024-42140 DLA-4008-1

Debian: CVE-2024-42145: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42145 CVE - 2024-42145 DSA-5747-1

Debian: CVE-2024-42101: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42101 CVE - 2024-42101 DSA-5747-1

Debian: CVE-2024-42230: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42230 CVE - 2024-42230 DLA-4008-1

VMware Photon OS: CVE-2024-42148 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/30/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of *regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues *is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for *slow-path interrupts) or Y+2 if CNIC is supported (one additional *FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE *L2 queue is supported. The cid for the FCoE L2 queue is always X. */ However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below. This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs. Stack traces: UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated--- Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-42148 CVE - 2024-42148

Debian: CVE-2024-42229: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:M/C:C/I:N/A:N) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42229 CVE - 2024-42229 DSA-5747-1

Debian: CVE-2024-42147: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42147 CVE - 2024-42147 DLA-4008-1

Debian: CVE-2022-48819: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/31/2024 Description In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48819 CVE - 2022-48819

Debian: CVE-2024-42152: linux, linux-6.1 -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 07/30/2024 Created 08/08/2024 Added 08/07/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-42152 CVE - 2024-42152 DSA-5747-1

Debian: CVE-2022-48815: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/31/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48815 CVE - 2022-48815

Debian: CVE-2022-48830: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/31/2024 Description In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix potential CAN frame reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48830 CVE - 2022-48830

Debian: CVE-2022-48827: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/31/2024 Description In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48827 CVE - 2022-48827

Debian: CVE-2022-48820: linux -- security update Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 07/30/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable() This error path needs to decrement "usbphyc->n_pll_cons.counter" before returning. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2022-48820 CVE - 2022-48820