Security Vulnerabilities
- CVEs Published In February 2025
In the Linux kernel, the following vulnerability has been resolved:
ntfs: add sanity check on allocation size
ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation
size. It triggers one BUG in the __ntfs_malloc function.
Fix this by adding sanity check on ni->attr_list_size.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not double complete bio on errors during compressed reads
I hit some weird panics while fixing up the error handling from
btrfs_lookup_bio_sums(). Turns out the compression path will complete
the bio we use if we set up any of the compression bios and then return
an error, and then btrfs_submit_data_bio() will also call bio_endio() on
the bio.
Fix this by making btrfs_submit_compressed_read() responsible for
calling bio_endio() on the bio if there are any errors. Currently it
was only doing it if we created the compression bios, otherwise it was
depending on btrfs_submit_data_bio() to do the right thing. This
creates the above problem, so fix up btrfs_submit_compressed_read() to
always call bio_endio() in case of an error, and then simply return from
btrfs_submit_data_bio() if we had to call
btrfs_submit_compressed_read().
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not clean up repair bio if submit fails
The submit helper will always run bio_endio() on the bio if it fails to
submit, so cleaning up the bio just leads to a variety of use-after-free
and NULL pointer dereference bugs because we race with the endio
function that is cleaning up the bio. Instead just return BLK_STS_OK as
the repair function has to continue to process the rest of the pages,
and the endio for the repair bio will do the appropriate cleanup for the
page that it was given.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix call timer start racing with call destruction
The rxrpc_call struct has a timer used to handle various timed events
relating to a call. This timer can get started from the packet input
routines that are run in softirq mode with just the RCU read lock held.
Unfortunately, because only the RCU read lock is held - and neither ref or
other lock is taken - the call can start getting destroyed at the same time
a packet comes in addressed to that call. This causes the timer - which
was already stopped - to get restarted. Later, the timer dispatch code may
then oops if the timer got deallocated first.
Fix this by trying to take a ref on the rxrpc_call struct and, if
successful, passing that ref along to the timer. If the timer was already
running, the ref is discarded.
The timer completion routine can then pass the ref along to the call's work
item when it queues it. If the timer or work item where already
queued/running, the extra ref is discarded.
In the Linux kernel, the following vulnerability has been resolved:
rtc: gamecube: Fix refcount leak in gamecube_rtc_read_offset_from_sram
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
In the Linux kernel, the following vulnerability has been resolved:
can: mcba_usb: properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. We should check that in endpoint is actually present to
prevent this warning.
Found pipes are now saved to struct mcba_priv and code uses them
directly instead of making pipes in place.
Fail log:
| usb 5-1: BOGUS urb xfer, pipe 3 != type 1
| WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| Modules linked in:
| CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0
| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| Workqueue: usb_hub_wq hub_event
| RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| ...
| Call Trace:
| <TASK>
| mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline]
| mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858
| usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
| call_driver_probe drivers/base/dd.c:517 [inline]
In the Linux kernel, the following vulnerability has been resolved:
XArray: Fix xas_create_range() when multi-order entry present
If there is already an entry present that is of order >= XA_CHUNK_SHIFT
when we call xas_create_range(), xas_create_range() will misinterpret
that entry as a node and dereference xa_node->parent, generally leading
to a crash that looks something like this:
general protection fault, probably for non-canonical address 0xdffffc0000000001:
0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0
RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline]
RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725
It's deterministically reproducable once you know what the problem is,
but producing it in a live kernel requires khugepaged to hit a race.
While the problem has been present since xas_create_range() was
introduced, I'm not aware of a way to hit it before the page cache was
converted to use multi-index entries.
In the Linux kernel, the following vulnerability has been resolved:
wireguard: socket: free skb in send6 when ipv6 is disabled
I got a memory leak report:
unreferenced object 0xffff8881191fc040 (size 232):
comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0
[<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340
[<ffffffff832974fb>] __alloc_skb+0x1db/0x200
[<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0
[<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110
[<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30
[<ffffffff8119c558>] process_one_work+0x2e8/0x770
[<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0
[<ffffffff811a88e0>] kthread+0x120/0x160
[<ffffffff8100242f>] ret_from_fork+0x1f/0x30
In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_
buffer_to_peer(), the semantics of send6() is required to free skb. But
when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it
to fix this bug.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: fix panic on out-of-bounds guest IRQ
As guest_irq is coming from KVM_IRQFD API call, it may trigger
crash in svm_update_pi_irte() due to out-of-bounds:
crash> bt
PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8"
#0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397
#1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d
#2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d
#3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d
#4 [ffffb1ba6707fb90] no_context at ffffffff856692c9
#5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51
#6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace
[exception RIP: svm_update_pi_irte+227]
RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086
RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001
RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8
RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200
R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm]
#8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm]
#9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm]
RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b
RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020
RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0
R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0
R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0
ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b
Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on
out-of-bounds guest IRQ), so we can just copy source from that to fix
this.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020
[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1
[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018
[ 12.356356] Call Trace:
[ 12.358821] dump_stack_lvl+0x34/0x44
[ 12.362514] check_preemption_disabled+0xd9/0xe0
[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]
[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40
[ 12.384284] local_pci_probe+0x42/0x80
[ 12.390162] ? pci_match_device+0xd7/0x110
[ 12.396366] pci_device_probe+0xfd/0x1b0
[ 12.402372] really_probe+0x1e7/0x3e0
[ 12.408114] __driver_probe_device+0xfe/0x180
[ 12.414544] driver_probe_device+0x1e/0x90
[ 12.420685] __driver_attach+0xc0/0x1c0
[ 12.426536] ? __device_attach_driver+0xe0/0xe0
[ 12.433061] ? __device_attach_driver+0xe0/0xe0
[ 12.439538] bus_for_each_dev+0x78/0xc0
[ 12.445294] bus_add_driver+0x12b/0x1e0
[ 12.451021] driver_register+0x8f/0xe0
[ 12.456631] ? 0xffffffffc07bc000
[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]
[ 12.468776] do_one_initcall+0x44/0x200
[ 12.474401] ? load_module+0xad3/0xba0
[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410
[ 12.486268] do_init_module+0x5c/0x280
[ 12.491730] __do_sys_init_module+0x12e/0x1b0
[ 12.497785] do_syscall_64+0x3b/0x90
[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 12.509764] RIP: 0033:0x7f554f73ab2e