CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-45026 – s390/dasd: fix error recovery leading to data corruption on ESE devices
https://notcve.org/view.php?id=CVE-2024-45026
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. • https://git.kernel.org/stable/c/5e2b17e712cf10cc3cc98fde28a88e8f1a1267e9 https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8 https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118 https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246 https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45025 – fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
https://notcve.org/view.php?id=CVE-2024-45025
In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c • https://git.kernel.org/stable/c/ee501f827f3db02d4e599afbbc1a7f8b792d05d7 https://git.kernel.org/stable/c/e807487a1d5fd5d941f26578ae826ca815dbfcd6 https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058 https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958 https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45021 – memcg_write_event_control(): fix a user-triggerable oops
https://notcve.org/view.php?id=CVE-2024-45021
In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). • https://git.kernel.org/stable/c/0dea116876eefc9c7ca9c5d74fe665481e499fa3 https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411 https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8 https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227 https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7 https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-45018 – netfilter: flowtable: initialise extack before use
https://notcve.org/view.php?id=CVE-2024-45018
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload. • https://git.kernel.org/stable/c/c29f74e0df7a02b8303bcdce93a7c0132d62577a https://git.kernel.org/stable/c/e5ceff2196dc633c995afb080f6f44a72cff6e1d https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7 https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78 https://git.kernel.org/stable/c/c7b760499f7791352b49b11667ed04b23d7f5b0f https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1 https://git.kernel.org/stable/c/e9767137308daf906496613fd879808a07f006a2 https://access.redhat.com/security/cve/CVE-2024-45018 •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-45016 – netem: fix return value if duplicate enqueue fails
https://notcve.org/view.php?id=CVE-2024-45016
In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS. • https://git.kernel.org/stable/c/5845f706388a4cde0f6b80f9e5d33527e942b7d9 https://git.kernel.org/stable/c/a550a01b8af856f2684b0f79d552f5119eb5006c https://git.kernel.org/stable/c/009510a90e230bb495f3fe25c7db956679263b07 https://git.kernel.org/stable/c/4de7d30668cb8b06330992e1cd336f91700a2ce7 https://git.kernel.org/stable/c/d1dd2e15c85e890a1cc9bde5ba07ae63331e5c73 https://git.kernel.org/stable/c/0148fe458b5705e2fea7cb88294fed7e36066ca2 https://git.kernel.org/stable/c/759e3e8c4a6a6b4e52ebc4547123a457f0ce90d4 https://git.kernel.org/stable/c/c414000da1c2ea1ba9a5e5bb1a4ba774e •