CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56686 – ext4: fix race in buffer_head read fault injection
https://notcve.org/view.php?id=CVE-2024-56686
In the Linux kernel, the following vulnerability has been resolved: ext4: fix race in buffer_head read fault injection When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() <bh read complete> ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty <report warning> WARN_ON_ONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection. • https://git.kernel.org/stable/c/46f870d690fecc792a66730dcbbf0aa109f5f9ab https://git.kernel.org/stable/c/77035e4d27e15f87ea55929c8bb8fb1970129e2f https://git.kernel.org/stable/c/25a5acf88fed59e060405bbb48098f4a3a2c2adc https://git.kernel.org/stable/c/61832ee7fa2fbd569d129379e795038abfb0d128 https://git.kernel.org/stable/c/2f3d93e210b9c2866c8b3662adae427d5bf511ec •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56685 – ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe
https://notcve.org/view.php?id=CVE-2024-56685
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero length, and only gets populated with the dummy struct after the card is registered. Since the sound card driver's probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior. This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card's node in the Devicetree, the default uninitialized dummy codec is used, and when its dai_name pointer gets passed to strcmp() it results in a null pointer dereference and a kernel panic. In addition to that, set_card_codec_info() in the generic helpers file, mtk-soundcard-driver.c, will populate a dai link with a dummy codec when a dai link node is present in DT but with no codec property. The result is that at probe time, a dummy codec can either be uninitialized with num_codecs = 0, or be an initialized dummy codec, with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs' fields but still check for the codec's dai name against "snd-soc-dummy-dai" as needed. While at it, also drop the check that dai_name is not null in the mt8192 driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing"), as it is actually redundant given the preceding num_codecs != 0 check. • https://git.kernel.org/stable/c/13f58267cda3d6946c8f4de368ad5d4a003baa61 https://git.kernel.org/stable/c/376f4800f34a28def026ff5c5d4fc5e54e1744ff https://git.kernel.org/stable/c/550279449ff54c5aa28cfca5c567308cbfb145f0 https://git.kernel.org/stable/c/2f2020327cc8561d7c520d2f2d9acea84fa7b3a3 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56683 – drm/vc4: hdmi: Avoid hang with debug registers when suspended
https://notcve.org/view.php?id=CVE-2024-56683
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Avoid hang with debug registers when suspended Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. • https://git.kernel.org/stable/c/25eb441d55d479581a65bcc9de88bc1d86bf76c1 https://git.kernel.org/stable/c/1da00a63f0e798f0fd0dcf623b16c16e13f93615 https://git.kernel.org/stable/c/f70c25cf34f91cc6f40e79a5b7565fd0272d7396 https://git.kernel.org/stable/c/0ea29bd7d9400d3629683244d609358ed1b12075 https://git.kernel.org/stable/c/c7d474974954d9af7e0092021223d58f2de128df https://git.kernel.org/stable/c/16f351adf733a182224ad24916d7673aa6df02df https://git.kernel.org/stable/c/74f21be9990a42dc2357bcf87a13e16c6998b90e https://git.kernel.org/stable/c/223ee2567a55e4f80315c768d2969e6a3 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56681 – crypto: bcm - add error check in the ahash_hmac_init function
https://notcve.org/view.php?id=CVE-2024-56681
In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahash_hmac_init function The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. • https://git.kernel.org/stable/c/9d12ba86f818aa9cfe9f01b750336aa441f2ffa2 https://git.kernel.org/stable/c/8f1a9a960b1107bd0e0ec3736055f5ed0e717edf https://git.kernel.org/stable/c/75e1e38e5d80d6d9011b7322698ffba3dd3db30a https://git.kernel.org/stable/c/28f8ffa945f7d7150463e15097ea73b19529d6f5 https://git.kernel.org/stable/c/4ea3e3b761e371102bb1486778e2f8dbc9e37413 https://git.kernel.org/stable/c/05f0a3f5477ecaa1cf46448504afe9e7c2e96fcc https://git.kernel.org/stable/c/ae5253313e0ea5f00c06176074592b7f493c8546 https://git.kernel.org/stable/c/ee36db8e8203420e6d5c42eb9428920c2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56679 – octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c
https://notcve.org/view.php?id=CVE-2024-56679
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c Add error pointer check after calling otx2_mbox_get_rsp(). • https://git.kernel.org/stable/c/ab58a416c93f134b72ec7e10d8d74509c3985243 https://git.kernel.org/stable/c/785c6758ea32aca73ba9331f7d902f7ce9a25757 https://git.kernel.org/stable/c/9265b6ee754226f61bd122ec57141a781d4e0dcb https://git.kernel.org/stable/c/52c63a6a27d3178fab533fcfb4baa2ed5b8608a3 https://git.kernel.org/stable/c/4b88b202cf1ae79159a94fff9500f9be31559235 https://git.kernel.org/stable/c/d4d5139d280f5837f16d116614c05c2b4eeaf28f https://git.kernel.org/stable/c/0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 •