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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49996 – cifs: Fix buffer overflow when parsing NFS reparse points
https://notcve.org/view.php?id=CVE-2024-49996
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev(). • https://git.kernel.org/stable/c/d5ecebc4900df7f6e8dff0717574668885110553 https://git.kernel.org/stable/c/c6db81c550cea0c73bd72ef55f579991e0e4ba07 https://git.kernel.org/stable/c/803b3a39cb096d8718c0aebc03fd19f11c7dc919 https://git.kernel.org/stable/c/c173d47b69f07cd7ca08efb4e458adbd4725d8e9 https://git.kernel.org/stable/c/e2a8910af01653c1c268984855629d71fb81f404 •