Security Vulnerabilities
- CVEs Published In November 2024
In the Linux kernel, the following vulnerability has been resolved:
iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP
generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem,
on huge=always tmpfs, issues a warning and then hangs (interruptibly):
WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9
CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2
...
copy_page_from_iter_atomic+0xa6/0x5ec
generic_perform_write+0xf6/0x1b4
shmem_file_write_iter+0x54/0x67
Fix copy_page_from_iter_atomic() by limiting it in that case
(include/linux/skbuff.h skb_frag_must_loop() does similar).
But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too
surprising, has outlived its usefulness, and should just be removed?
In the Linux kernel, the following vulnerability has been resolved:
sched/numa: Fix the potential null pointer dereference in task_numa_work()
When running stress-ng-vm-segv test, we found a null pointer dereference
error in task_numa_work(). Here is the backtrace:
[323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
......
[323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se
......
[323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)
[323676.067115] pc : vma_migratable+0x1c/0xd0
[323676.067122] lr : task_numa_work+0x1ec/0x4e0
[323676.067127] sp : ffff8000ada73d20
[323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010
[323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000
[323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000
[323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8
[323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035
[323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8
[323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4
[323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001
[323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000
[323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000
[323676.067152] Call trace:
[323676.067153] vma_migratable+0x1c/0xd0
[323676.067155] task_numa_work+0x1ec/0x4e0
[323676.067157] task_work_run+0x78/0xd8
[323676.067161] do_notify_resume+0x1ec/0x290
[323676.067163] el0_svc+0x150/0x160
[323676.067167] el0t_64_sync_handler+0xf8/0x128
[323676.067170] el0t_64_sync+0x17c/0x180
[323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)
[323676.067177] SMP: stopping secondary CPUs
[323676.070184] Starting crashdump kernel...
stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error
handling function of the system, which tries to cause a SIGSEGV error on
return from unmapping the whole address space of the child process.
Normally this program will not cause kernel crashes. But before the
munmap system call returns to user mode, a potential task_numa_work()
for numa balancing could be added and executed. In this scenario, since the
child process has no vma after munmap, the vma_next() in task_numa_work()
will return a null pointer even if the vma iterator restarts from 0.
Recheck the vma pointer before dereferencing it in task_numa_work().
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-dspi: Fix crash when not using GPIO chip select
Add check for the return value of spi_get_csgpiod() to avoid passing a NULL
pointer to gpiod_direction_output(), preventing a crash when GPIO chip
select is not used.
Fix below crash:
[ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 4.260762] Mem abort info:
[ 4.263556] ESR = 0x0000000096000004
[ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits
[ 4.272624] SET = 0, FnV = 0
[ 4.275681] EA = 0, S1PTW = 0
[ 4.278822] FSC = 0x04: level 0 translation fault
[ 4.283704] Data abort info:
[ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 4.302445] [0000000000000000] user address but active_mm is swapper
[ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 4.315072] Modules linked in:
[ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359
[ 4.328130] Hardware name: LS1046A QDS Board (DT)
[ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.339794] pc : gpiod_direction_output+0x34/0x5c
[ 4.344505] lr : gpiod_direction_output+0x18/0x5c
[ 4.349208] sp : ffff80008003b8f0
[ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068
[ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810
[ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002
[ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff
[ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007
[ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e
[ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008
[ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000
[ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000
[ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000
[ 4.423921] Call trace:
[ 4.426362] gpiod_direction_output+0x34/0x5c (P)
[ 4.431067] gpiod_direction_output+0x18/0x5c (L)
[ 4.435771] dspi_setup+0x220/0x334
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix error propagation of split bios
The purpose of btrfs_bbio_propagate_error() shall be propagating an error
of split bio to its original btrfs_bio, and tell the error to the upper
layer. However, it's not working well on some cases.
* Case 1. Immediate (or quick) end_bio with an error
When btrfs sends btrfs_bio to mirrored devices, btrfs calls
btrfs_bio_end_io() when all the mirroring bios are completed. If that
btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function
is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error()
accesses the orig_bbio's bio context to increase the error count.
That works well in most cases. However, if the end_io is called enough
fast, orig_bbio's (remaining part after split) bio context may not be
properly set at that time. Since the bio context is set when the orig_bbio
(the last btrfs_bio) is sent to devices, that might be too late for earlier
split btrfs_bio's completion. That will result in NULL pointer
dereference.
That bug is easily reproducible by running btrfs/146 on zoned devices [1]
and it shows the following trace.
[1] You need raid-stripe-tree feature as it create "-d raid0 -m raid1" FS.
BUG: kernel NULL pointer dereference, address: 0000000000000020
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback wb_workfn (flush-btrfs-5)
RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs]
BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0
RSP: 0018:ffffc9000006f248 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc
RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080
RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58
R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158
FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __die_body.cold+0x19/0x26
? page_fault_oops+0x13e/0x2b0
? _printk+0x58/0x73
? do_user_addr_fault+0x5f/0x750
? exc_page_fault+0x76/0x240
? asm_exc_page_fault+0x22/0x30
? btrfs_bio_end_io+0xae/0xc0 [btrfs]
? btrfs_log_dev_io_error+0x7f/0x90 [btrfs]
btrfs_orig_write_end_io+0x51/0x90 [btrfs]
dm_submit_bio+0x5c2/0xa50 [dm_mod]
? find_held_lock+0x2b/0x80
? blk_try_enter_queue+0x90/0x1e0
__submit_bio+0xe0/0x130
? ktime_get+0x10a/0x160
? lockdep_hardirqs_on+0x74/0x100
submit_bio_noacct_nocheck+0x199/0x410
btrfs_submit_bio+0x7d/0x150 [btrfs]
btrfs_submit_chunk+0x1a1/0x6d0 [btrfs]
? lockdep_hardirqs_on+0x74/0x100
? __folio_start_writeback+0x10/0x2c0
btrfs_submit_bbio+0x1c/0x40 [btrfs]
submit_one_bio+0x44/0x60 [btrfs]
submit_extent_folio+0x13f/0x330 [btrfs]
? btrfs_set_range_writeback+0xa3/0xd0 [btrfs]
extent_writepage_io+0x18b/0x360 [btrfs]
extent_write_locked_range+0x17c/0x340 [btrfs]
? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]
run_delalloc_cow+0x71/0xd0 [btrfs]
btrfs_run_delalloc_range+0x176/0x500 [btrfs]
? find_lock_delalloc_range+0x119/0x260 [btrfs]
writepage_delalloc+0x2ab/0x480 [btrfs]
extent_write_cache_pages+0x236/0x7d0 [btrfs]
btrfs_writepages+0x72/0x130 [btrfs]
do_writepages+0xd4/0x240
? find_held_lock+0x2b/0x80
? wbc_attach_and_unlock_inode+0x12c/0x290
? wbc_attach_and_unlock_inode+0x12c/0x29
---truncated---
In the Linux kernel, the following vulnerability has been resolved:
drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()
modprobe drm_hdmi_state_helper_test and then rmmod it, the following
memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xffffff80ccd18100 (size 128):
comm "kunit_try_catch", pid 1851, jiffies 4295059695
hex dump (first 32 bytes):
57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ .....
ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................
backtrace (crc c2f1aa95):
[<000000000f10b11b>] kmemleak_alloc+0x34/0x40
[<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4
[<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c
[<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98
[<0000000019daaacf>] 0xffffffedc11ae69c
[<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac
[<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000a0b2e9e>] kthread+0x2e8/0x374
[<00000000bd668858>] ret_from_fork+0x10/0x20
......
Free `mode` by using drm_kunit_display_mode_from_cea_vic()
to fix it.
In the Linux kernel, the following vulnerability has been resolved:
drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()
modprobe drm_connector_test and then rmmod drm_connector_test,
the following memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xffffff80cb0ee400 (size 128):
comm "kunit_try_catch", pid 1948, jiffies 4294950339
hex dump (first 32 bytes):
14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8.
3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e...........
backtrace (crc 90e9585c):
[<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40
[<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4
[<00000000c2062161>] drm_mode_duplicate+0x44/0x19c
[<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98
[<00000000d8f2c8b4>] 0xffffffdc982a4868
[<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac
[<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000006ea56ca0>] kthread+0x2e8/0x374
[<000000000676063f>] ret_from_fork+0x10/0x20
......
Free `mode` by using drm_kunit_display_mode_from_cea_vic()
to fix it.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: assign dh_key to NULL after kfree_sensitive
ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup()
for the same controller. So it's better to nullify it after release on
error path in order to avoid double free later in nvmet_destroy_auth().
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix finding a last resort AG in xfs_filestream_pick_ag
When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG. But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set. Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.
In the Linux kernel, the following vulnerability has been resolved:
lib: alloc_tag_module_unload must wait for pending kfree_rcu calls
Ben Greear reports following splat:
------------[ cut here ]------------
net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload
WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0
Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat
...
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020
RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0
codetag_unload_module+0x19b/0x2a0
? codetag_load_module+0x80/0x80
nf_nat module exit calls kfree_rcu on those addresses, but the free
operation is likely still pending by the time alloc_tag checks for leaks.
Wait for outstanding kfree_rcu operations to complete before checking
resolves this warning.
Reproducer:
unshare -n iptables-nft -t nat -A PREROUTING -p tcp
grep nf_nat /proc/allocinfo # will list 4 allocations
rmmod nft_chain_nat
rmmod nf_nat # will WARN.
[akpm@linux-foundation.org: add comment]
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in quomodosoft ElementsReady Addons for Elementor element-ready-lite allows Stored XSS.This issue affects ElementsReady Addons for Elementor: from n/a through <= 6.4.3.