CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50001 – net/mlx5: Fix error path in multi-packet WQE transmit
https://notcve.org/view.php?id=CVE-2024-50001
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure. • https://git.kernel.org/stable/c/5af75c747e2a868abbf8611494b50ed5e076fca7 https://git.kernel.org/stable/c/ca36d6c1a49b6965c86dd528a73f38bc62d9c625 https://git.kernel.org/stable/c/ce828b347cf1b3c1b12b091d02463c35ce5097f5 https://git.kernel.org/stable/c/fc357e78176945ca7bcacf92ab794b9ccd41b4f4 https://git.kernel.org/stable/c/26fad69b34fcba80d5c7d9e651f628e6ac927754 https://git.kernel.org/stable/c/ecf310aaf256acbc8182189fe0aa1021c3ddef72 https://git.kernel.org/stable/c/8bb8c12fb5e2b1f03d603d493c92941676f109b5 https://git.kernel.org/stable/c/2bcae12c795f32ddfbf8c80d1b5f1d328 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50000 – net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
https://notcve.org/view.php?id=CVE-2024-50000
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/a6696735d694b365bca45873e9dbca26120a8375 https://git.kernel.org/stable/c/4655456a64a0f936098c8432bac64e7176bd2aff https://git.kernel.org/stable/c/b48ee5bb25c02ca2b81e0d16bf8af17ab6ed3f8b https://git.kernel.org/stable/c/0168ab6fbd9e50d20b97486168b604b2ab28a2ca https://git.kernel.org/stable/c/1bcc86cc721bea68980098f51f102aa2c2b9d932 https://git.kernel.org/stable/c/4d80dde26d7bab1320210279483ac854dcb274b2 https://git.kernel.org/stable/c/f25389e779500cf4a59ef9804534237841bce536 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49999 – afs: Fix the setting of the server responding flag
https://notcve.org/view.php?id=CVE-2024-49999
In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag. • https://git.kernel.org/stable/c/98f9fda2057ba34b720c4d353351024d6dcee90f https://git.kernel.org/stable/c/3d51ab44123f35dd1d646d99a15ebef10f55e263 https://git.kernel.org/stable/c/97c953572d98080c5f1486155350bb688041747a https://git.kernel.org/stable/c/ff98751bae40faed1ba9c6a7287e84430f7dec64 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49998 – net: dsa: improve shutdown sequence
https://notcve.org/view.php?id=CVE-2024-49998
In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. • https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5 https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7 https://git.kernel.org/stable/c/ab5d3420a1120950703dbdc33698b28a6ebc3d23 https://git.kernel.org/stable/c/b4a65d479213fe84ecb14e328271251eebe69492 https://git.kernel.org/stable/c/6c24a03a61a245fe34d47582898331fa034b6ccd •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49997 – net: ethernet: lantiq_etop: fix memory disclosure
https://notcve.org/view.php?id=CVE-2024-49997
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. • https://git.kernel.org/stable/c/504d4721ee8e432af4b5f196a08af38bc4dac5fe https://git.kernel.org/stable/c/905f06a34f960676e7dc77bea00f2f8fe18177ad https://git.kernel.org/stable/c/60c068444c20bf9a3e22b65b5f6f3d9edc852931 https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36 https://git.kernel.org/stable/c/469856f76f4802c5d7e3d20e343185188de1e2db https://git.kernel.org/stable/c/2bf4c101d7c99483b8b15a0c8f881e3f399f7e18 https://git.kernel.org/stable/c/e66e38d07b31e177ca430758ed97fbc79f27d966 https://git.kernel.org/stable/c/1097bf16501ed5e35358d848b0a94ad28 •