deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-43945
Published: 2024-10-21
Description: Cross-Site Request Forgery (CSRF) vulnerability in Latepoint LatePoint allows Cross Site Request Forgery.This issue affects LatePoint: from n/a through 4.9.91.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-352
References: https://patchstack.com/database/vulnerability/latepoint/wordpress-latepoint-plugin-4-9-91-cross-site-request-forgery-csrf-vulnerability?_s_id=cve
CVE: CVE-2024-47328
Published: 2024-10-21
Description: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Aman FunnelKit Automations wp-marketing-automations allows SQL Injection.This issue affects FunnelKit Automations: from n/a through <= 3.1.2.
CVSS Score: 7.6 (HIGH)
CWE: CWE-89
References: https://patchstack.com/database/Wordpress/Plugin/wp-marketing-automations/vulnerability/wordpress-recover-woocommerce-cart-abandonment-newsletter-email-marketing-marketing-automation-by-funnelkit-plugin-3-1-2-sql-injection-vulnerability?_s_id=cve
CVE: CVE-2024-47675
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()

If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the
error_free label and frees the array of bpf_uprobe's without calling
bpf_uprobe_unregister().

This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer
without removing it from the uprobe->consumers list.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5fe6e308abaea082c20fbf2aa5df8e14495622cf; https://git.kernel.org/stable/c/790c630ab0e7d7aba6d186581d4627c09fce60f3; https://git.kernel.org/stable/c/7c1d782e5afbf7c50ba74ecc4ddc18a05d63e5ee
CVE: CVE-2024-47676
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway

Syzbot reports a UAF in hugetlb_fault().  This happens because
vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA
to be freed before hugetlb_vma_unlock_read() is called.

We can fix this by using a modified version of vmf_anon_prepare() that
doesn't release the VMA lock on failure, and then release it ourselves
after hugetlb_vma_unlock_read().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/98b74bb4d7e96b4da5ef3126511febe55b76b807; https://git.kernel.org/stable/c/d59ebc99dee0a2687a26df94b901eb8216dbf876; https://git.kernel.org/stable/c/e897d184a8dd4a4e1f39c8c495598e4d9472776c
CVE: CVE-2024-47677
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: resolve memory leak from exfat_create_upcase_table()

If exfat_load_upcase_table reaches end and returns -EINVAL,
allocated memory doesn't get freed and while
exfat_load_default_upcase_table allocates more memory, leading to a
memory leak.

Here's link to syzkaller crash report illustrating this issue:
https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/331ed2c739ce656a67865f6b3ee0a478349d78cb; https://git.kernel.org/stable/c/c290fe508eee36df1640c3cb35dc8f89e073c8a8; https://git.kernel.org/stable/c/f9835aec49670c46ebe2973032caaa1043b3d4da
CVE: CVE-2024-47678
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

icmp: change the order of rate limits

ICMP messages are ratelimited :

After the blamed commits, the two rate limiters are applied in this order:

1) host wide ratelimit (icmp_global_allow())

2) Per destination ratelimit (inetpeer based)

In order to avoid side-channels attacks, we need to apply
the per destination check first.

This patch makes the following change :

1) icmp_global_allow() checks if the host wide limit is reached.
   But credits are not yet consumed. This is deferred to 3)

2) The per destination limit is checked/updated.
   This might add a new node in inetpeer tree.

3) icmp_global_consume() consumes tokens if prior operations succeeded.

This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.

As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-203
References: https://git.kernel.org/stable/c/483397b4ba280813e4a9c161a0a85172ddb43d19; https://git.kernel.org/stable/c/662ec52260cc07b9ae53ecd3925183c29d34288b; https://git.kernel.org/stable/c/8c2bd38b95f75f3d2a08c93e35303e26d480d24e
CVE: CVE-2024-47679
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  ->spin_lock(inode)
  ->dec i_count to 0
  ->iput_final()                    generic_shutdown_super()
    ->__inode_add_lru()               ->evict_inodes()
      // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   ->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  ->find_inode()
    // found the above inode 261
    ->spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      ->__iget()
    ->spin_unlock(inode)                // schedule back
                                        ->spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  ->spin_unlock(inode)
  ->spin_lock(inode)			  ->evict()
  // dec i_count to 0
  ->iput_final()
    ->spin_unlock()
    ->evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/[PII_REDACTED]00eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb; https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1; https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b
CVE: CVE-2024-47680
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: check discard support for conventional zones

As the helper function f2fs_bdev_support_discard() shows, f2fs checks if
the target block devices support discard by calling
bdev_max_discard_sectors() and bdev_is_zoned(). This check works well
for most cases, but it does not work for conventional zones on zoned
block devices. F2fs assumes that zoned block devices support discard,
and calls __submit_discard_cmd(). When __submit_discard_cmd() is called
for sequential write required zones, it works fine since
__submit_discard_cmd() issues zone reset commands instead of discard
commands. However, when __submit_discard_cmd() is called for
conventional zones, __blkdev_issue_discard() is called even when the
devices do not support discard.

The inappropriate __blkdev_issue_discard() call was not a problem before
the commit 30f1e7241422 ("block: move discard checks into the ioctl
handler") because __blkdev_issue_discard() checked if the target devices
support discard or not. If not, it returned EOPNOTSUPP. After the
commit, __blkdev_issue_discard() no longer checks it. It always returns
zero and sets NULL to the given bio pointer. This NULL pointer triggers
f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the
commands below at the umount step, where /dev/nullb0 is a zoned null_blk
with 5GB total size, 128MB zone size and 10 conventional zones.

$ mkfs.f2fs -f -m /dev/nullb0
$ mount /dev/nullb0 /mnt
$ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done
$ umount /mnt

To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call.
When discard is requested for conventional zones, check if the device
supports discard or not. If not, return EOPNOTSUPP.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/43aec4d01bd2ce961817a777b3846f8318f398e4; https://git.kernel.org/stable/c/7bd7ce68ddad5a28565e42ef21cacaff113773a9; https://git.kernel.org/stable/c/d2352b57897f6a3349666fc318dcbec99092c6a5
CVE: CVE-2024-47681
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he

Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he
routine adding an sta interface to the mt7996 driver.

Found by code review.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/174c803b432596cdd7dd3ec5e0ec52b561969ee2; https://git.kernel.org/stable/c/1afdde3b5f56217d875a543cf565075c11bbddad; https://git.kernel.org/stable/c/8e4b60ae8a047ad2fb175fcfdd54feee80983a45
CVE: CVE-2024-47682
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: sd: Fix off-by-one error in sd_read_block_characteristics()

Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for
example), sd_read_block_characteristics() may attempt an out-of-bounds
memory access when accessing the zoned field at offset 8.
CVSS Score: 7.8 (HIGH)
CWE: CWE-193
References: https://git.kernel.org/stable/c/413df704f149dec585df07466d2401bbd1f490a0; https://git.kernel.org/stable/c/568c7c4c77eee6df7677bb861b7cee7398a3255d; https://git.kernel.org/stable/c/60312ae7392f9c75c6591a52fc359cf7f810d48f
CVE: CVE-2024-47683
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Skip Recompute DSC Params if no Stream on Link

[why]
Encounter NULL pointer dereference uner mst + dsc setup.

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
    Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
    RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
    Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
    RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
    RAX: [PII_REDACTED] RBX: ffff8afb87e81280 RCX: [PII_REDACTED]
    RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
    RBP: ffff8afb83d67000 R08: [PII_REDACTED] R09: ffff8afb9652f850
    R10: ffff960cc2df7908 R11: [PII_REDACTED] R12: [PII_REDACTED]
    R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: [PII_REDACTED]
    FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:[PII_REDACTED]
    CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
    CR2: [PII_REDACTED] CR3: 000000010ddc6000 CR4:[PII_REDACTED]3506e0
    Call Trace:
<TASK>
     ? __die+0x23/0x70
     ? page_fault_oops+0x171/0x4e0
     ? plist_add+0xbe/0x100
     ? exc_page_fault+0x7c/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e[PII_REDACTED]8d8e02b741593dd50d80b44c2026]
     ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e[PII_REDACTED]8d8e02b741593dd50d80b44c2026]
     compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     drm_atomic_check_only+0x5c5/0xa40
     drm_mode_atomic_ioctl+0x76e/0xbc0

[how]
dsc recompute should be skipped if no mode change detected on the new
request. If detected, keep checking whether the stream is already on
current state or not.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9; https://git.kernel.org/stable/c/50e376f1fe3bf571d0645ddf48ad37eb58323919; https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad
CVE: CVE-2024-47686
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()

The psc->div[] array has psc->num_div elements.  These values come from
when we call clk_hw_register_div().  It's adc_divisors and
ARRAY_SIZE(adc_divisors)) and so on.  So this condition needs to be >=
instead of > to prevent an out of bounds read.
CVSS Score: 7.1 (HIGH)
CWE: CWE-193
References: https://git.kernel.org/stable/c/27f493e141823db052586010c1532b70b164507c; https://git.kernel.org/stable/c/66e78ade976dbd9bea09166aa8d66afc0963cde4; https://git.kernel.org/stable/c/7a5bd2fb92388c51d267f6ce57c40f1cca8af1e0
CVE: CVE-2024-47689
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()

syzbot reports a f2fs bug as below:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
 percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
 destroy_super_work+0xec/0x130 fs/super.c:282
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb->s_umount semaphore via remount procedure, then below
race condition causes this bug:

- freeze_super()
 - sb_wait_write(sb, SB_FREEZE_WRITE)
 - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
 - sb_wait_write(sb, SB_FREEZE_FS)
					- f2fs_handle_critical_error
					 - sb->s_flags |= SB_RDONLY
- thaw_super
 - thaw_super_locked
  - sb_rdonly() is true, so it skips
    sb_freeze_unlock(sb, SB_FREEZE_FS)
  - deactivate_locked_super

Since f2fs has almost the same logic as ext4 [2] when handling critical
error in filesystem if it mounts w/ errors=remount-ro option:
- set CP_ERROR_FLAG flag which indicates filesystem is stopped
- record errors to superblock
- set SB_RDONLY falg
Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the
flag and stop any further updates on filesystem. So, it is safe to not
set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3].

[1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner
[2] https://lore.kernel.org/all/[PII_REDACTED]2721.hxih6ehigadqf7wx@quack3
[3] https://lore.kernel.org/linux-ext4/[PII_REDACTED]1241.27286-1-jack@suse.cz
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1f63f405c1a1a64b9c310388aad7055fb86b245c; https://git.kernel.org/stable/c/649ec8b30df113042588bd3d3cd4e98bcb1091e0; https://git.kernel.org/stable/c/930c6ab93492c4b15436524e704950b364b2930c
CVE: CVE-2024-47690
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: get rid of online repaire on corrupted directory

syzbot reports a f2fs bug as below:

kernel BUG at fs/f2fs/inode.c:896!
RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
Call Trace:
 evict+0x532/0x950 fs/inode.c:704
 dispose_list fs/inode.c:747 [inline]
 evict_inodes+0x5f9/0x690 fs/inode.c:797
 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627
 kill_block_super+0x44/0x90 fs/super.c:1696
 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898
 deactivate_locked_super+0xc4/0x130 fs/super.c:473
 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373
 task_work_run+0x24f/0x310 kernel/task_work.c:228
 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402
 ptrace_report_syscall include/linux/ptrace.h:415 [inline]
 ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]
 syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173
 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]
 syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218
 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896

Online repaire on corrupted directory in f2fs_lookup() can generate
dirty data/meta while racing w/ readonly remount, it may leave dirty
inode after filesystem becomes readonly, however, checkpoint() will
skips flushing dirty inode in a state of readonly mode, result in
above panic.

Let's get rid of online repaire in f2fs_lookup(), and leave the work
to fsck.f2fs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/884ee6dc85b959bc152f15bca80c30f06069e6c4; https://git.kernel.org/stable/c/8be95cd607478d85fa4626e86f811e785905bcbf; https://git.kernel.org/stable/c/bcefd0b0611f35b560d0a7281d87529fbe7a1e32
CVE: CVE-2024-47691
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()

syzbot reports a f2fs bug as below:

 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_report+0xe8/0x550 mm/kasan/report.c:491
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
 atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
 __refcount_add include/linux/refcount.h:184 [inline]
 __refcount_inc include/linux/refcount.h:241 [inline]
 refcount_inc include/linux/refcount.h:258 [inline]
 get_task_struct include/linux/sched/task.h:118 [inline]
 kthread_stop+0xca/0x630 kernel/kthread.c:704
 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210
 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283
 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]
 __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The root cause is below race condition, it may cause use-after-free
issue in sbi->gc_th pointer.

- remount
 - f2fs_remount
  - f2fs_stop_gc_thread
   - kfree(gc_th)
				- f2fs_ioc_shutdown
				 - f2fs_do_shutdown
				  - f2fs_stop_gc_thread
				   - kthread_stop(gc_th->f2fs_gc_task)
   : sbi->gc_thread = NULL;

We will call f2fs_do_shutdown() in two paths:
- for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore
for fixing.
- for f2fs_shutdown() path, it's safe since caller has already grabbed
sb->s_umount semaphore.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/7c339dee7eb0f8e4cadc317c595f898ef04dae30; https://git.kernel.org/stable/c/c7f114d864ac91515bb07ac271e9824a20f5ed95; https://git.kernel.org/stable/c/d79343cd66343709e409d96b2abb139a0a55ce34
CVE: CVE-2024-47692
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: return -EINVAL when namelen is 0

When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
result in namelen being 0, which will cause memdup_user() to return
ZERO_SIZE_PTR.
When we access the name.data that has been assigned the value of
ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
triggered.

[ T1205] ==================================================================
[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
[ T1205] Read of size 1 at addr [PII_REDACTED] by task nfsdcld/1205
[ T1205]
[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ T1205] Call Trace:
[ T1205]  dump_stack+0x9a/0xd0
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  __kasan_report.cold+0x34/0x84
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  kasan_report+0x3a/0x50
[ T1205]  nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  ? nfsd4_release_lockowner+0x410/0x410
[ T1205]  cld_pipe_downcall+0x5ca/0x760
[ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
[ T1205]  ? down_write_killable_nested+0x170/0x170
[ T1205]  ? avc_policy_seqno+0x28/0x40
[ T1205]  ? selinux_file_permission+0x1b4/0x1e0
[ T1205]  rpc_pipe_write+0x84/0xb0
[ T1205]  vfs_write+0x143/0x520
[ T1205]  ksys_write+0xc9/0x170
[ T1205]  ? __ia32_sys_read+0x50/0x50
[ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110
[ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110
[ T1205]  do_syscall_64+0x33/0x40
[ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1
[ T1205] RIP: 0033:0x7fdbdb761bc7
[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
[ T1205] RAX: ffffffffffffffda RBX:[PII_REDACTED]00042b RCX: 00007fdbdb761bc7
[ T1205] RDX:[PII_REDACTED]00042b RSI: 00007fff8c4b75f0 RDI: [PII_REDACTED]
[ T1205] RBP: 00007fdbdb761bb0 R08: [PII_REDACTED] R09: [PII_REDACTED]
[ T1205] R10: [PII_REDACTED] R11: [PII_REDACTED] R12:[PII_REDACTED]00042b
[ T1205] R13: [PII_REDACTED] R14: 00007fff8c4b75f0 R15: [PII_REDACTED]
[ T1205] ==================================================================

Fix it by checking namelen.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0f1d007bbea38a61cf9c5392708dc70ae9d84a3d; https://git.kernel.org/stable/c/1ff8be8d008b9ddc8e7043fbddd37d5d451b271b; https://git.kernel.org/stable/c/22451a16b7ab7debefce660672566be887db1637