| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()
If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer
and its dereference with priv_ep->cdns3_dev may cause panic.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: xhci_plat_remove: avoid NULL dereference
Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host:
xhci-plat: omit shared hcd if either root hub has no ports")
xhci->shared_hcd can be NULL, which causes the following Oops
on reboot:
[ 710.124450] systemd-shutdown[1]: Rebooting.
[ 710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 710.304217] usb usb3: USB disconnect, device number 1
[ 710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered
[ 710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1
[ 710.328401] usb usb2: USB disconnect, device number 1
[ 710.333515] usb 2-3: USB disconnect, device number 2
[ 710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[ 710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8
[ 710.484425] Mem abort info:
[ 710.487265] ESR = 0x0000000096000004
[ 710.491060] EC = 0x25: DABT (current EL), IL = 32 bits
[ 710.496427] SET = 0, FnV = 0
[ 710.499525] EA = 0, S1PTW = 0
[ 710.502716] FSC = 0x04: level 0 translation fault
[ 710.507648] Data abort info:
[ 710.510577] ISV = 0, ISS = 0x00000004
[ 710.514462] CM = 0, WnR = 0
[ 710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000
[ 710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000
[ 710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6
[ 710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1
[ 710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022
[ 710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 710.597949] pc : usb_remove_hcd+0x34/0x1e4
[ 710.602067] lr : xhci_plat_remove+0x74/0x140
[ 710.606351] sp : ffff800009f3b7c0
[ 710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000
[ 710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000
[ 710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800
[ 710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff
[ 710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c
[ 710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0
[ 710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4
[ 710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001
[ 710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000
[ 710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000
[ 710.681251] Call trace:
[ 710.683704] usb_remove_hcd+0x34/0x1e4
[ 710.687467] xhci_plat_remove+0x74/0x140
[ 710.691400] platform_remove+0x34/0x70
[ 710.695165] device_remove+0x54/0x90
[ 710.698753] device_release_driver_internal+0x200/0x270
[ 710.703992] device_release_driver+0x24/0x30
[ 710.708273] bus_remove_device+0xe0/0x16c
[ 710.712293] device_del+0x178/0x390
[ 710.715797] platform_device_del.part.0+0x24/0x90
[ 710.720514] platform_device_unregister+0x30/0x50
[ 710.725232] dwc3_host_exit+0x20/0x30
[ 710.728907] dwc3_remove+0x174/0x1b0
[ 710.732494] platform_remove+0x34/0x70
[ 710.736254] device_remove+0x54/0x90
[ 710.739840] device_release_driver_internal+0x200/0x270
[ 710.745078] device_release_driver+0x24/0x30
[ 710.749359] bus_remove_device+0xe0/0x16c
[ 710.753380] device_del+0x178/0x390
[ 710.756881] platform_device_del.part
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup
The function rxe_create_qp calls rxe_qp_from_init. If some error
occurs, the error handler of function rxe_qp_from_init will set
both scq and rcq to NULL.
Then rxe_create_qp calls rxe_put to handle qp. In the end,
rxe_qp_do_cleanup is called by rxe_put. rxe_qp_do_cleanup directly
accesses scq and rcq before checking them. This will cause
null-ptr-deref error.
The call graph is as below:
rxe_create_qp {
...
rxe_qp_from_init {
...
err1:
...
qp->rcq = NULL; <---rcq is set to NULL
qp->scq = NULL; <---scq is set to NULL
...
}
qp_init:
rxe_put{
...
rxe_qp_do_cleanup {
...
atomic_dec(&qp->scq->num_wq); <--- scq is accessed
...
atomic_dec(&qp->rcq->num_wq); <--- rcq is accessed
}
} |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate session id and tree id in the compound request
This patch validate session id and tree id in compound request.
If first operation in the compound is SMB2 ECHO request, ksmbd bypass
session and tree validation. So work->sess and work->tcon could be NULL.
If secound request in the compound access work->sess or tcon, It cause
NULL pointer dereferecing error. |
| In the Linux kernel, the following vulnerability has been resolved:
configfs-tsm-report: Fix NULL dereference of tsm_ops
Unlike sysfs, the lifetime of configfs objects is controlled by
userspace. There is no mechanism for the kernel to find and delete all
created config-items. Instead, the configfs-tsm-report mechanism has an
expectation that tsm_unregister() can happen at any time and cause
established config-item access to start failing.
That expectation is not fully satisfied. While tsm_report_read(),
tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail
if tsm_ops have been unregistered, tsm_report_privlevel_store()
tsm_report_provider_show() fail to check for ops registration. Add the
missing checks for tsm_ops having been removed.
Now, in supporting the ability for tsm_unregister() to always succeed,
it leaves the problem of what to do with lingering config-items. The
expectation is that the admin that arranges for the ->remove() (unbind)
of the ${tsm_arch}-guest driver is also responsible for deletion of all
open config-items. Until that deletion happens, ->probe() (reload /
bind) of the ${tsm_arch}-guest driver fails.
This allows for emergency shutdown / revocation of attestation
interfaces, and requires coordinated restart. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: only dirty folios when data journaling regular files
fstest generic/388 occasionally reproduces a crash that looks as
follows:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
<TASK>
ext4_block_zero_page_range+0x30c/0x380 [ext4]
ext4_truncate+0x436/0x440 [ext4]
ext4_process_orphan+0x5d/0x110 [ext4]
ext4_orphan_cleanup+0x124/0x4f0 [ext4]
ext4_fill_super+0x262d/0x3110 [ext4]
get_tree_bdev_flags+0x132/0x1d0
vfs_get_tree+0x26/0xd0
vfs_cmd_create+0x59/0xe0
__do_sys_fsconfig+0x4ed/0x6b0
do_syscall_64+0x82/0x170
...
This occurs when processing a symlink inode from the orphan list. The
partial block zeroing code in the truncate path calls
ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls
mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an
a_ops vector in ext4, hence the crash.
To avoid this problem, update the ext4_dirty_journalled_data() helper to
only mark the folio dirty on regular files (for which a_ops is
assigned). This also matches the journaling logic in the ext4_symlink()
creation path, where ext4_handle_dirty_metadata() is called directly. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Verify content returned by parse_int_array()
The first element of the returned array stores its length. If it is 0,
any manipulation beyond the element at index 0 ends with null-ptr-deref. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw
Search result of avs_dai_find_path_template() shall be verified before
being used. As 'template' is already known when
avs_hw_constraints_init() is fired, drop the search entirely. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: avoid NULL pointer dereference in mt7996_set_monitor()
The function mt7996_set_monitor() dereferences phy before
the NULL sanity check.
Fix this to avoid NULL pointer dereference by moving the
dereference after the check. |
| A flaw was found in libsoup, where the soup_message_headers_get_content_disposition() function is vulnerable to a NULL pointer dereference. This flaw allows a malicious HTTP peer to crash a libsoup client or server that uses this function. |
| In the Linux kernel, the following vulnerability has been resolved:
tee: add overflow check in register_shm_helper()
With special lengths supplied by user space, register_shm_helper() has
an integer overflow when calculating the number of pages covered by a
supplied user space memory region.
This causes internal_get_user_pages_fast() a helper function of
pin_user_pages_fast() to do a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Modules linked in:
CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
pc : internal_get_user_pages_fast+0x474/0xa80
Call trace:
internal_get_user_pages_fast+0x474/0xa80
pin_user_pages_fast+0x24/0x4c
register_shm_helper+0x194/0x330
tee_shm_register_user_buf+0x78/0x120
tee_ioctl+0xd0/0x11a0
__arm64_sys_ioctl+0xa8/0xec
invoke_syscall+0x48/0x114
Fix this by adding an an explicit call to access_ok() in
tee_shm_register_user_buf() to catch an invalid user space address
early. |
| In the Linux kernel, the following vulnerability has been resolved:
locking/csd_lock: Change csdlock_debug from early_param to __setup
The csdlock_debug kernel-boot parameter is parsed by the
early_param() function csdlock_debug(). If set, csdlock_debug()
invokes static_branch_enable() to enable csd_lock_wait feature, which
triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and
CONFIG_SPARSEMEM_VMEMMAP=n.
With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in
static_key_enable() and returns NULL, resulting in a NULL dereference
because mem_section is initialized only later in sparse_init().
This is also a problem for powerpc because early_param() functions
are invoked earlier than jump_label_init(), also resulting in
static_key_enable() failures. These failures cause the warning "static
key 'xxx' used before call to jump_label_init()".
Thus, early_param is too early for csd_lock_wait to run
static_branch_enable(), so changes it to __setup to fix these. |
| In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix potential NULL dereference in __kernfs_remove
When lockdep is enabled, lockdep_assert_held_write would
cause potential NULL pointer dereference.
Fix the following smatch warnings:
fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346) |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/eprobes: Have event probes be consistent with kprobes and uprobes
Currently, if a symbol "@" is attempted to be used with an event probe
(eprobes), it will cause a NULL pointer dereference crash.
Both kprobes and uprobes can reference data other than the main registers.
Such as immediate address, symbols and the current task name. Have eprobes
do the same thing.
For "comm", if "comm" is used and the event being attached to does not
have the "comm" field, then make it the "$comm" that kprobes has. This is
consistent to the way histograms and filters work. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
While playing with event probes (eprobes), I tried to see what would
happen if I attempted to retrieve the instruction pointer (%rip) knowing
that event probes do not use pt_regs. The result was:
BUG: kernel NULL pointer dereference, address: 0000000000000024
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
v03.03 07/14/2016
RIP: 0010:get_event_field.isra.0+0x0/0x50
Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8
50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24
8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74
RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086
RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000
RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8
R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8
R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0
Call Trace:
<TASK>
get_eprobe_size+0xb4/0x640
? __mod_node_page_state+0x72/0xc0
__eprobe_trace_func+0x59/0x1a0
? __mod_lruvec_page_state+0xaa/0x1b0
? page_remove_file_rmap+0x14/0x230
? page_remove_rmap+0xda/0x170
event_triggers_call+0x52/0xe0
trace_event_buffer_commit+0x18f/0x240
trace_event_raw_event_sched_wakeup_template+0x7a/0xb0
try_to_wake_up+0x260/0x4c0
__wake_up_common+0x80/0x180
__wake_up_common_lock+0x7c/0xc0
do_notify_parent+0x1c9/0x2a0
exit_notify+0x1a9/0x220
do_exit+0x2ba/0x450
do_group_exit+0x2d/0x90
__x64_sys_exit_group+0x14/0x20
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Obviously this is not the desired result.
Move the testing for TPARG_FL_TPOINT which is only used for event probes
to the top of the "$" variable check, as all the other variables are not
used for event probes. Also add a check in the register parsing "%" to
fail if an event probe is used. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix dummy res NULL ptr deref bug
Check the bo->resource value before accessing the resource
mem_type.
v2: Fix commit description unwrapped warning
<log snip>
[ 40.191227][ T184] general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
[ 40.192995][ T184] KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
[ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 #1
[ 40.196063][ T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
[ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm]
[ 40.200754][ T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58
[ 40.203685][ T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202
[ 40.204630][ T184] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff1102f4bb71b
[ 40.205864][ T184] RDX: 0000000000000002 RSI: ffffc900006df208 RDI: 0000000000000010
[ 40.207102][ T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000
[ 40.208394][ T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110
[ 40.209692][ T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208
[ 40.210862][ T184] FS: 00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000
[ 40.212250][ T184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 40.213275][ T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0
[ 40.214469][ T184] Call Trace:
[ 40.214974][ T184] <TASK>
[ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm]
[ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240
[ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm]
[ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm]
[ 40.219410][ T184] ? shmem_get_inode+0x744/0x980
[ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm]
[ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
[ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm]
[ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0
[ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280
[ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper]
[ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
[ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180
[ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper]
[ 40.238864][ T184] ? local_pci_probe+0xdf/0x180
[ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper]
[ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm]
[ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm]
[ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm]
[ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper]
[ 40.245226][ T184] ? __cond_resched+0x1c/0xc0
[ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper]
[ 40.247316][ T184] ? mutex_unlock+0x80/0x100
[ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0
[ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper]
[ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper]
[ 40.251540][ T184] ? __cond_resched+0x1c/0xc0
[ 40.252321][ T184] ? mutex_lock+0x9f/0x100
[ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper]
[ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper]
[ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper]
[ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs]
[
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
BPF: Fix potential bad pointer dereference in bpf_sys_bpf()
The bpf_sys_bpf() helper function allows an eBPF program to load another
eBPF program from within the kernel. In this case the argument union
bpf_attr pointer (as well as the insns and license pointers inside) is a
kernel address instead of a userspace address (which is the case of a
usual bpf() syscall). To make the memory copying process in the syscall
work in both cases, bpfptr_t was introduced to wrap around the pointer
and distinguish its origin. Specifically, when copying memory contents
from a bpfptr_t, a copy_from_user() is performed in case of a userspace
address and a memcpy() is performed for a kernel address.
This can lead to problems because the in-kernel pointer is never checked
for validity. The problem happens when an eBPF syscall program tries to
call bpf_sys_bpf() to load a program but provides a bad insns pointer --
say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()
which would then call bpf_prog_load() to load the program.
bpf_prog_load() is responsible for copying the eBPF instructions to the
newly allocated memory for the program; it creates a kernel bpfptr_t for
insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t
operations are backed by the corresponding sockptr_t operations, which
performs direct memcpy() on kernel pointers for copy_from/strncpy_from
operations. Therefore, the code is always happy to dereference the bad
pointer to trigger a un-handle-able page fault and in turn an oops.
However, this is not supposed to happen because at that point the eBPF
program is already verified and should not cause a memory error.
Sample KASAN trace:
[ 25.685056][ T228] ==================================================================
[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30
[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228
[ 25.686732][ T228]
[ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7
[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
[ 25.687991][ T228] Call Trace:
[ 25.688223][ T228] <TASK>
[ 25.688429][ T228] dump_stack_lvl+0x73/0x9e
[ 25.688747][ T228] print_report+0xea/0x200
[ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30
[ 25.689401][ T228] ? _printk+0x54/0x6e
[ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0
[ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30
[ 25.690412][ T228] kasan_report+0xb5/0xe0
[ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30
[ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0
[ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30
[ 25.691734][ T228] memcpy+0x25/0x60
[ 25.692000][ T228] copy_from_bpfptr+0x21/0x30
[ 25.692328][ T228] bpf_prog_load+0x604/0x9e0
[ 25.692653][ T228] ? cap_capable+0xb4/0xe0
[ 25.692956][ T228] ? security_capable+0x4f/0x70
[ 25.693324][ T228] __sys_bpf+0x3af/0x580
[ 25.693635][ T228] bpf_sys_bpf+0x45/0x240
[ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd
[ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0
[ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0
[ 25.695144][ T228] bpf_prog_test_run+0x172/0x190
[ 25.695487][ T228] __sys_bpf+0x2c5/0x580
[ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50
[ 25.696084][ T228] do_syscall_64+0x60/0x90
[ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60
[ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0
[ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40
[ 25.697586][ T228] ? do_syscall_64+0x6e/0x90
[ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 25.698312][ T228] RIP: 0033:0x7f6d543fb759
[ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()
As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI
pointer values"), we need to perform a null pointer check on the return
value of ice_get_vf_vsi() before using it. |
| In the Linux kernel, the following vulnerability has been resolved:
net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null
Fixes a NULL pointer derefence bug triggered from tap driver.
When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null
(in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)
virtio_net_hdr_to_skb calls dev_parse_header_protocol which
needs skb->dev field to be valid.
The line that trigers the bug is in dev_parse_header_protocol
(dev is at offset 0x10 from skb and is stored in RAX register)
if (!dev->header_ops || !dev->header_ops->parse_protocol)
22e1: mov 0x10(%rbx),%rax
22e5: mov 0x230(%rax),%rax
Setting skb->dev before the call in tap.c fixes the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000230
RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]
Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48
RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010
RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300
RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8
R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6
FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0
Call Trace:
tap_get_user+0x3f1/0x540 [tap]
tap_sendmsg+0x56/0x362 [tap]
? get_tx_bufs+0xc2/0x1e0 [vhost_net]
handle_tx_copy+0x114/0x670 [vhost_net]
handle_tx+0xb0/0xe0 [vhost_net]
handle_tx_kick+0x15/0x20 [vhost_net]
vhost_worker+0x7b/0xc0 [vhost]
? vhost_vring_call_reset+0x40/0x40 [vhost]
kthread+0xfa/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()
A NULL pointer dereference can occur in skb_dequeue() when processing a
QCA firmware crash dump on WCN7851 (0489:e0f3).
[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)
[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]
[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80
The issue stems from handle_dump_pkt_qca() returning 0 even when a dump
packet is successfully processed. This is because it incorrectly
forwards the return value of hci_devcd_init() (which returns 0 on
success). As a result, the caller (btusb_recv_acl_qca() or
btusb_recv_evt_qca()) assumes the packet was not handled and passes it
to hci_recv_frame(), leading to premature kfree() of the skb.
Later, hci_devcd_rx() attempts to dequeue the same skb from the dump
queue, resulting in a NULL pointer dereference.
Fix this by:
1. Making handle_dump_pkt_qca() return 0 on success and negative errno
on failure, consistent with kernel conventions.
2. Splitting dump packet detection into separate functions for ACL
and event packets for better structure and readability.
This ensures dump packets are properly identified and consumed, avoiding
double handling and preventing NULL pointer access. |
