CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44969 – s390/sclp: Prevent release of buffer in I/O
https://notcve.org/view.php?id=CVE-2024-44969
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction. • https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05 https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148 https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463 https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79 https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633 https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506 https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44968 – tick/broadcast: Move per CPU pointer access into the atomic section
https://notcve.org/view.php?id=CVE-2024-44968
In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Move per CPU pointer access into the atomic section The recent fix for making the take over of the broadcast timer more reliable retrieves a per CPU pointer in preemptible context. This went unnoticed as compilers hoist the access into the non-preemptible region where the pointer is actually used. But of course it's valid that the compiler keeps it at the place where the code puts it which rightfully triggers: BUG: using smp_processor_id() in preemptible [00000000] code: caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0 Move it to the actual usage site which is in a non-preemptible region. • https://git.kernel.org/stable/c/408bfb6b0a7f22e971ce6b600aec448769e580a8 https://git.kernel.org/stable/c/3a58c590f6bd1d20eb1e76c5cea31c36cc032339 https://git.kernel.org/stable/c/2cdab4b4bf77369961f706cdeb7d040db10c5217 https://git.kernel.org/stable/c/7b3ec186ba93e333e9efe7254e7e31c1828e5d2d https://git.kernel.org/stable/c/b9d604933d5fd72dd37f24e1dc35f778297d745a https://git.kernel.org/stable/c/7dd12f85f150010ef7518201c63fa7e395f5c3e9 https://git.kernel.org/stable/c/f54abf332a2bc0413cfa8bd6a8511f7aa99faea0 https://git.kernel.org/stable/c/f91fb47ecacc178a83a77eeebd25cbaec •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-44967 – drm/mgag200: Bind I2C lifetime to DRM device
https://notcve.org/view.php?id=CVE-2024-44967
In the Linux kernel, the following vulnerability has been resolved: drm/mgag200: Bind I2C lifetime to DRM device Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter. • https://git.kernel.org/stable/c/b279df242972ae816a75cf1cc732af836f999100 https://git.kernel.org/stable/c/55a6916db77102765b22855d3a0add4751988b7c https://git.kernel.org/stable/c/81d34df843620e902dd04aa9205c875833d61c17 https://git.kernel.org/stable/c/9d96b91e03cba9dfcb4ac370c93af4dbc47d5191 https://git.kernel.org/stable/c/eb1ae34e48a09b7a1179c579aed042b032e408f4 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-44966 – binfmt_flat: Fix corruption when not offsetting data start
https://notcve.org/view.php?id=CVE-2024-44966
In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. • https://git.kernel.org/stable/c/04d82a6d0881ef1ab1e9f66f10805177ee2fb1e8 https://git.kernel.org/stable/c/3a684499261d0f7ed5ee72793025c88c2276809c https://git.kernel.org/stable/c/af65d5383854cc3f172a7d0843b628758bf462c8 https://git.kernel.org/stable/c/49df34d2b7da9e57c839555a2f7877291ce45ad1 https://git.kernel.org/stable/c/9350ba06ee61db392c486716ac68ecc20e030f7c https://git.kernel.org/stable/c/3eb3cd5992f7a0c37edc8d05b4c38c98758d8671 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44965 – x86/mm: Fix pti_clone_pgtable() alignment assumption
https://notcve.org/view.php?id=CVE-2024-44965
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions. • https://git.kernel.org/stable/c/16a3fe634f6a568c6234b8747e5d50487fed3526 https://git.kernel.org/stable/c/18da1b27ce16a14a9b636af9232acb4fb24f4c9e https://git.kernel.org/stable/c/25a727233a40a9b33370eec9f0cad67d8fd312f8 https://git.kernel.org/stable/c/d00c9b4bbc442d99e1dafbdfdab848bc1ead73f6 https://git.kernel.org/stable/c/4d143ae782009b43b4f366402e5c37f59d4e4346 https://git.kernel.org/stable/c/5c580c1050bcbc15c3e78090859d798dcf8c9763 https://git.kernel.org/stable/c/ca07aab70dd3b5e7fddb62d7a6ecd7a7d6d0b2ed https://git.kernel.org/stable/c/df3eecb5496f87263d171b254ca6e2758 •