CVE-2024-26757

In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore read-only array in md_check_recovery()

Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:

1. array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb

2. register new sync thread concurrently.

3. dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro

4. stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

5. sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread);

6. daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;

The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore read-only array in md_check_recovery()

Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:

1. array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb

2. register new sync thread concurrently.

3. dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro

4. stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

5. sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread);

6. daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;

The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

Root has patched CVE-2024-26757 in the linux package for Root:Debian:11. Multiple fixed versions available.

Root has patched CVE-2024-26757 in the linux package for Root:Debian:12. Multiple fixed versions available.

Root has patched CVE-2024-26757 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

The SUSE Linux Enterprise 15 SP6 Azure kernel was updated to receive various security bugfixes.

The following security bugs were fixed:

• CVE-2024-22099: Fixed a null-pointer-dereference in rfcomm_check_security (bsc#1219170).
• CVE-2024-26764: Fixed IOCB_AIO_RW check in fs/aio before the struct aio_kiocb conversion (bsc#1222721).
• CVE-2024-26862: Fixed packet annotate data-races around ignore_outgoing (bsc#1223111).
• CVE-2024-26673: Fixed netfilter/nft_ct layer 3 and 4 protocol sanitization (bsc#1222368).
• CVE-2023-0160: Fixed deadlock flaw in BPF that could allow a local user to potentially crash the system (bsc#1209657).
• CVE-2024-26993: Fixed fs/sysfs reference leak in sysfs_break_active_protection() (bsc#1223693).
• CVE-2024-27013: Fixed tun limit printing rate when illegal packet received by tun device (bsc#1223745).
• CVE-2024-27014: Fixed net/mlx5e to prevent deadlock while disabling aRFS (bsc#1223735).
• CVE-2024-26948: Fixed drm/amd/display by adding dc_state NULL check in dc_state_release (bsc#1223664).
• CVE-2024-27056: Fixed wifi/iwlwifi/mvm to ensure offloading TID queue exists (bsc#1223822).
• CVE-2024-26960: Fixed mm/swap race between free_swap_and_cache() and swapoff() (bsc#1223655).
• CVE-2023-52652: Fixed NTB for possible name leak in ntb_register_device() (bsc#1223686).
• CVE-2024-23848: Fixed media/cec for possible use-after-free in cec_queue_msg_fh (bsc#1219104).
• CVE-2024-26982: Fixed Squashfs inode number check not to be an invalid value of zero (bsc#1223634).
• CVE-2024-26878: Fixed quota for potential NULL pointer dereference (bsc#1223060).
• CVE-2024-26901: Fixed do_sys_name_to_handle() to use kzalloc() to prevent kernel-infoleak (bsc#1223198).
• CVE-2024-26671: Fixed blk-mq IO hang from sbitmap wakeup race (bsc#1222357).
• CVE-2024-26772: Fixed ext4 to avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() (bsc#1222613).
• CVE-2024-26906: Disallowed vsyscall page read for copy_from_kernel_nofault() (bsc#1223202).
• CVE-2024-26816: Ignore relocations in .notes section when building with CONFIG_XEN_PV=y (bsc#1222624).
• CVE-2024-26783: Fixed mm/vmscan bug when calling wakeup_kswapd() with a wrong zone index (bsc#1222615).
• CVE-2024-26883: Fixed bpf stackmap overflow check on 32-bit arches (bsc#1223035).
• CVE-2024-26884: Fixed bpf hashtab overflow check on 32-bit arches (bsc#1223189).
• CVE-2024-26885: Fixed bpf DEVMAP_HASH overflow check on 32-bit arches (bsc#1223190).
• CVE-2024-26882: Fixed net/ip_tunnel to make sure to pull inner header in ip_tunnel_rcv() (bsc#1223034).
• CVE-2023-52645: Fixed pmdomain/mediatek race conditions with genpd (bsc#1223033).
• CVE-2024-26836: Fixed platform/x86/think-lmi password opcode ordering for workstations (bsc#1222968).
• CVE-2024-26601: Fixed ext4 buddy bitmap corruption via fast commit replay (bsc#1220342).
• CVE-2024-26773: Fixed ext4 block allocation from corrupted group in ext4_mb_try_best_found() (bsc#1222618).
• CVE-2024-26807: Fixed spi/cadence-qspi NULL pointer reference in runtime PM hooks (bsc#1222801).
• CVE-2024-26737: Fixed selftests/bpf racing between bpf_timer_cancel_and_free and bpf_timer_cancel (bsc#1222557).
• CVE-2024-26733: Fixed an overflow in arp_req_get() in arp (bsc#1222585).
• CVE-2024-26684: Fixed net/stmmac/xgmac handling of DPP safety error for DMA channels (bsc#1222445).
• CVE-2024-26704: Fixed a double-free of blocks due to wrong extents moved_len in ext4 (bsc#1222422).
• CVE-2023-52591: Fixed a possible reiserfs filesystem corruption via directory renaming (bsc#1221044).
• CVE-2023-52503: Fixed tee/amdtee use-after-free vulnerability in amdtee_close_session (bsc#1220915).
• CVE-2024-26642: Fixed the set of anonymous timeout flag in netfilter nf_tables (bsc#1221830).
• CVE-2024-26614: Fixed the initialization of accept_queue's spinlocks (bsc#1221293).
• CVE-2024-25739: Fixed possible crash in create_empty_lvol() in drivers/mtd/ubi/vtbl.c (bsc#1219834).
• CVE-2023-6270: Fixed a use-after-free issue in…