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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44964 – idpf: fix memory leaks and crashes while performing a soft reset
https://notcve.org/view.php?id=CVE-2024-44964
In the Linux kernel, the following vulnerability has been resolved: idpf: fix memory leaks and crashes while performing a soft reset The second tagged commit introduced a UAF, as it removed restoring q_vector->vport pointers after reinitializating the structures. This is due to that all queue allocation functions are performed here with the new temporary vport structure and those functions rewrite the backpointers to the vport. Then, this new struct is freed and the pointers start leading to nowhere. But generally speaking, the current logic is very fragile. It claims to be more reliable when the system is low on memory, but in fact, it consumes two times more memory as at the moment of running this function, there are two vports allocated with their queues and vectors. Moreover, it claims to prevent the driver from running into "bad state", but in fact, any error during the rebuild leaves the old vport in the partially allocated state. Finally, if the interface is down when the function is called, it always allocates a new queue set, but when the user decides to enable the interface later on, vport_open() allocates them once again, IOW there's a clear memory leak here. Just don't allocate a new queue set when performing a reset, that solves crashes and memory leaks. Readd the old queue number and reopen the interface on rollback - that solves limbo states when the device is left disabled and/or without HW queues enabled. • https://git.kernel.org/stable/c/02cbfba1add5bd9088c7d14c6b93b77a6ea8f3bb https://git.kernel.org/stable/c/6b289f8d91537ec1e4f9c7b38b31b90d93b1419b https://git.kernel.org/stable/c/f01032a2ca099ec8d619aaa916c3762aa62495df •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44963 – btrfs: do not BUG_ON() when freeing tree block after error
https://notcve.org/view.php?id=CVE-2024-44963
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() when freeing tree block after error When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block(). So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection. • https://git.kernel.org/stable/c/98251cd60b4d702a8a81de442ab621e83a3fb24f https://git.kernel.org/stable/c/bb3868033a4cccff7be57e9145f2117cbdc91c11 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44962 – Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading
https://notcve.org/view.php?id=CVE-2024-44962
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) • https://git.kernel.org/stable/c/4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016 https://git.kernel.org/stable/c/28bbb5011a9723700006da67bdb57ab6a914452b https://git.kernel.org/stable/c/0d0df1e750bac0fdaa77940e711c1625cff08d33 •