| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
gpu: lontium-lt9611: Fix NULL pointer dereference in lt9611_connector_init()
A NULL check for bridge->encoder shows that it may be NULL, but it
already been dereferenced on all paths leading to the check.
812 if (!bridge->encoder) {
Dereference the pointer bridge->encoder.
810 drm_connector_attach_encoder(<9611->connector, bridge->encoder); |
| In the Linux kernel, the following vulnerability has been resolved:
net: broadcom: bcm4908_enet: update TX stats after actual transmission
Queueing packets doesn't guarantee their transmission. Update TX stats
after hardware confirms consuming submitted data.
This also fixes a possible race and NULL dereference.
bcm4908_enet_start_xmit() could try to access skb after freeing it in
the bcm4908_enet_poll_tx(). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: musb: Fix musb_gadget.c rxstate overflow bug
The usb function device call musb_gadget_queue() adds the passed
request to musb_ep::req_list,If the (request->length > musb_ep->packet_sz)
and (is_buffer_mapped(req) return false),the rxstate() will copy all data
in fifo to request->buf which may cause request->buf out of bounds.
Fix it by add the length check :
fifocnt = min_t(unsigned, request->length - request->actual, fifocnt); |
| In the Linux kernel, the following vulnerability has been resolved:
of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()
When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 will
be NULL, and strcmp() will cause null pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: Fix refcount leak in erdma_mmap
rdma_user_mmap_entry_get() take reference, we should release it when not
need anymore, add the missing rdma_user_mmap_entry_put() in the error
path to fix it. |
| The Strong Testimonials plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check in the 'edit_rating' function in all versions up to, and including, 3.2.18. This makes it possible for authenticated attackers with Contributor-level access and above to modify or delete the rating meta on any testimonial post, including those created by other users, by reusing a valid nonce obtained from their own testimonial edit screen. |
| In the Linux kernel, the following vulnerability has been resolved:
MIPS: fw: Allow firmware to pass a empty env
fw_getenv will use env entry to determine style of env,
however it is legal for firmware to just pass a empty list.
Check if first entry exist before running strchr to avoid
null pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vmem: split pages when debug pagealloc is enabled
Since commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")
the kernel crashes early during boot when debug pagealloc is enabled:
mem auto-init: stack:off, heap alloc:off, heap free:off
addressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630
[..]
Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e
00000000001325fc: eb880002000c srlg %r8,%r8,2
#0000000000132602: b2210051 ipte %r5,%r1,%r0,0
>0000000000132606: b90400d1 lgr %r13,%r1
000000000013260a: 41605008 la %r6,8(%r5)
000000000013260e: a7db1000 aghi %r13,4096
0000000000132612: b221006d ipte %r6,%r13,%r0,0
0000000000132616: e3d0d0000171 lay %r13,4096(%r13)
Call Trace:
__kernel_map_pages+0x14e/0x320
__free_pages_ok+0x23a/0x5a8)
free_low_memory_core_early+0x214/0x2c8
memblock_free_all+0x28/0x58
mem_init+0xb6/0x228
mm_core_init+0xb6/0x3b0
start_kernel+0x1d2/0x5a8
startup_continue+0x36/0x40
Kernel panic - not syncing: Fatal exception: panic_on_oops
This is caused by using large mappings on machines with EDAT1/EDAT2. Add
the code to split the mappings into 4k pages if debug pagealloc is enabled
by CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel
command line option. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: udlfb: Fix endpoint check
The syzbot fuzzer detected a problem in the udlfb driver, caused by an
endpoint not having the expected type:
usb 1-1: Read EDID byte 0 failed: -71
usb 1-1: Unable to get valid EDID from device/display
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/28/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
<TASK>
dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743
The current approach for this issue failed to catch the problem
because it only checks for the existence of a bulk-OUT endpoint; it
doesn't check whether this endpoint is the one that the driver will
actually use.
We can fix the problem by instead checking that the endpoint used by
the driver does exist and is bulk-OUT. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net
Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd
startup") moved the initialization of the reply cache into nfsd startup,
but didn't account for the stats counters, which can be accessed before
nfsd is ever started. The result can be a NULL pointer dereference when
someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still
shut down.
This is a regression and a user-triggerable oops in the right situation:
- non-x86_64 arch
- /proc/fs/nfsd is mounted in the namespace
- nfsd is not started in the namespace
- unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"
Although this is easy to trigger on some arches (like aarch64), on
x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the
fixed_percpu_data. That struct looks just enough like a newly
initialized percpu var to allow nfsd_reply_cache_stats_show to access
it without Oopsing.
Move the initialization of the per-net+per-cpu reply-cache counters
back into nfsd_init_net, while leaving the rest of the reply cache
allocations to be done at nfsd startup time.
Kudos to Eirik who did most of the legwork to track this down. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: Fix memory leak in ath11k_peer_rx_frag_setup
crypto_alloc_shash() allocates resources, which should be released by
crypto_free_shash(). When ath11k_peer_find() fails, there has memory
leak. Add missing crypto_free_shash() to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Add a check for valid 'mad_agent' pointer
When unregistering MAD agent, srpt module has a non-null check
for 'mad_agent' pointer before invoking ib_unregister_mad_agent().
This check can pass if 'mad_agent' variable holds an error value.
The 'mad_agent' can have an error value for a short window when
srpt_add_one() and srpt_remove_one() is executed simultaneously.
In srpt module, added a valid pointer check for 'sport->mad_agent'
before unregistering MAD agent.
This issue can hit when RoCE driver unregisters ib_device
Stack Trace:
------------
BUG: kernel NULL pointer dereference, address: 000000000000004d
PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P
Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020
Workqueue: bnxt_re bnxt_re_task [bnxt_re]
RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40
Call Trace:
ib_unregister_mad_agent+0x46/0x2f0 [ib_core]
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
? __schedule+0x20b/0x560
srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]
srpt_remove_one+0x20/0x150 [ib_srpt]
remove_client_context+0x88/0xd0 [ib_core]
bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex
disable_device+0x8a/0x160 [ib_core]
bond0: active interface up!
? kernfs_name_hash+0x12/0x80
(NULL device *): Bonding Info Received: rdev: 000000006c0b8247
__ib_unregister_device+0x42/0xb0 [ib_core]
(NULL device *): Master: mode: 4 num_slaves:2
ib_unregister_device+0x22/0x30 [ib_core]
(NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0
bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]
bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re] |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix leak of dev tracker
At the stage of direction checks, the netdev reference tracker is
already initialized, but released with wrong *_put() call. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a possible null-pointer dereference in ni_clear()
In a previous commit c1006bd13146, ni->mi.mrec in ni_write_inode()
could be NULL, and thus a NULL check is added for this variable.
However, in the same call stack, ni->mi.mrec can be also dereferenced
in ni_clear():
ntfs_evict_inode(inode)
ni_write_inode(inode, ...)
ni = ntfs_i(inode);
is_rec_inuse(ni->mi.mrec) -> Add a NULL check by previous commit
ni_clear(ntfs_i(inode))
is_rec_inuse(ni->mi.mrec) -> No check
Thus, a possible null-pointer dereference may exist in ni_clear().
To fix it, a NULL check is added in this function. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init
blk-iocost sometimes causes the following crash:
BUG: kernel NULL pointer dereference, address: 00000000000000e0
...
RIP: 0010:_raw_spin_lock+0x17/0x30
Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 <f0> 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00
RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001
RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0
RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003
R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000
R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600
FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0
Call Trace:
<TASK>
ioc_weight_write+0x13d/0x410
cgroup_file_write+0x7a/0x130
kernfs_fop_write_iter+0xf5/0x170
vfs_write+0x298/0x370
ksys_write+0x5f/0xb0
__x64_sys_write+0x1b/0x20
do_syscall_64+0x3d/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
This happens because iocg->ioc is NULL. The field is initialized by
ioc_pd_init() and never cleared. The NULL deref is caused by
blkcg_activate_policy() installing blkg_policy_data before initializing it.
blkcg_activate_policy() was doing the following:
1. Allocate pd's for all existing blkg's and install them in blkg->pd[].
2. Initialize all pd's.
3. Online all pd's.
blkcg_activate_policy() only grabs the queue_lock and may release and
re-acquire the lock as allocation may need to sleep. ioc_weight_write()
grabs blkcg->lock and iterates all its blkg's. The two can race and if
ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a
pd which is not initialized yet, leading to crash.
The crash can be reproduced with the following script:
#!/bin/bash
echo +io > /sys/fs/cgroup/cgroup.subtree_control
systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct
echo 100 > /sys/fs/cgroup/system.slice/io.weight
bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" &
sleep .2
echo 100 > /sys/fs/cgroup/system.slice/io.weight
with the following patch applied:
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index fc49be622e05..38d671d5e10c 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)
> pd->online = false;
> }
>
> + if (system_state == SYSTEM_RUNNING) {
> + spin_unlock_irq(&q->queue_lock);
> + ssleep(1);
> + spin_lock_irq(&q->queue_lock);
> + }
> +
> /* all allocated, init in the same order */
> if (pol->pd_init_fn)
> list_for_each_entry_reverse(blkg, &q->blkg_list, q_node)
I don't see a reason why all pd's should be allocated, initialized and
onlined together. The only ordering requirement is that parent blkgs to be
initialized and onlined before children, which is guaranteed from the
walking order. Let's fix the bug by allocating, initializing and onlining pd
for each blkg and holding blkcg->lock over initialization and onlining. This
ensures that an installed blkg is always fully initialized and onlined
removing the the race window. |
| In the Linux kernel, the following vulnerability has been resolved:
media: usb: siano: Fix use after free bugs caused by do_submit_urb
There are UAF bugs caused by do_submit_urb(). One of the KASan reports
is shown below:
[ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890
[ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49
[ 36.408316]
[ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8
[ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[ 36.416157] Workqueue: 0x0 (events)
[ 36.417654] Call Trace:
[ 36.418546] <TASK>
[ 36.419320] dump_stack_lvl+0x96/0xd0
[ 36.420522] print_address_description+0x75/0x350
[ 36.421992] print_report+0x11b/0x250
[ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0
[ 36.424806] ? __virt_addr_valid+0xcf/0x170
[ 36.426069] ? worker_thread+0x4a2/0x890
[ 36.427355] kasan_report+0x131/0x160
[ 36.428556] ? worker_thread+0x4a2/0x890
[ 36.430053] worker_thread+0x4a2/0x890
[ 36.431297] ? worker_clr_flags+0x90/0x90
[ 36.432479] kthread+0x166/0x190
[ 36.433493] ? kthread_blkcg+0x50/0x50
[ 36.434669] ret_from_fork+0x22/0x30
[ 36.435923] </TASK>
[ 36.436684]
[ 36.437215] Allocated by task 24:
[ 36.438289] kasan_set_track+0x50/0x80
[ 36.439436] __kasan_kmalloc+0x89/0xa0
[ 36.440566] smsusb_probe+0x374/0xc90
[ 36.441920] usb_probe_interface+0x2d1/0x4c0
[ 36.443253] really_probe+0x1d5/0x580
[ 36.444539] __driver_probe_device+0xe3/0x130
[ 36.446085] driver_probe_device+0x49/0x220
[ 36.447423] __device_attach_driver+0x19e/0x1b0
[ 36.448931] bus_for_each_drv+0xcb/0x110
[ 36.450217] __device_attach+0x132/0x1f0
[ 36.451470] bus_probe_device+0x59/0xf0
[ 36.452563] device_add+0x4ec/0x7b0
[ 36.453830] usb_set_configuration+0xc63/0xe10
[ 36.455230] usb_generic_driver_probe+0x3b/0x80
[ 36.456166] printk: console [ttyGS0] disabled
[ 36.456569] usb_probe_device+0x90/0x110
[ 36.459523] really_probe+0x1d5/0x580
[ 36.461027] __driver_probe_device+0xe3/0x130
[ 36.462465] driver_probe_device+0x49/0x220
[ 36.463847] __device_attach_driver+0x19e/0x1b0
[ 36.465229] bus_for_each_drv+0xcb/0x110
[ 36.466466] __device_attach+0x132/0x1f0
[ 36.467799] bus_probe_device+0x59/0xf0
[ 36.469010] device_add+0x4ec/0x7b0
[ 36.470125] usb_new_device+0x863/0xa00
[ 36.471374] hub_event+0x18c7/0x2220
[ 36.472746] process_one_work+0x34c/0x5b0
[ 36.474041] worker_thread+0x4b7/0x890
[ 36.475216] kthread+0x166/0x190
[ 36.476267] ret_from_fork+0x22/0x30
[ 36.477447]
[ 36.478160] Freed by task 24:
[ 36.479239] kasan_set_track+0x50/0x80
[ 36.480512] kasan_save_free_info+0x2b/0x40
[ 36.481808] ____kasan_slab_free+0x122/0x1a0
[ 36.483173] __kmem_cache_free+0xc4/0x200
[ 36.484563] smsusb_term_device+0xcd/0xf0
[ 36.485896] smsusb_probe+0xc85/0xc90
[ 36.486976] usb_probe_interface+0x2d1/0x4c0
[ 36.488303] really_probe+0x1d5/0x580
[ 36.489498] __driver_probe_device+0xe3/0x130
[ 36.491140] driver_probe_device+0x49/0x220
[ 36.492475] __device_attach_driver+0x19e/0x1b0
[ 36.493988] bus_for_each_drv+0xcb/0x110
[ 36.495171] __device_attach+0x132/0x1f0
[ 36.496617] bus_probe_device+0x59/0xf0
[ 36.497875] device_add+0x4ec/0x7b0
[ 36.498972] usb_set_configuration+0xc63/0xe10
[ 36.500264] usb_generic_driver_probe+0x3b/0x80
[ 36.501740] usb_probe_device+0x90/0x110
[ 36.503084] really_probe+0x1d5/0x580
[ 36.504241] __driver_probe_device+0xe3/0x130
[ 36.505548] driver_probe_device+0x49/0x220
[ 36.506766] __device_attach_driver+0x19e/0x1b0
[ 36.508368] bus_for_each_drv+0xcb/0x110
[ 36.509646] __device_attach+0x132/0x1f0
[ 36.510911] bus_probe_device+0x59/0xf0
[ 36.512103] device_add+0x4ec/0x7b0
[ 36.513215] usb_new_device+0x863/0xa00
[ 36.514736] hub_event+0x18c7/0x2220
[ 36.516130] process_one_work+
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: double free xprt_ctxt while still in use
When an RPC request is deferred, the rq_xprt_ctxt pointer is moved out
of the svc_rqst into the svc_deferred_req.
When the deferred request is revisited, the pointer is copied into
the new svc_rqst - and also remains in the svc_deferred_req.
In the (rare?) case that the request is deferred a second time, the old
svc_deferred_req is reused - it still has all the correct content.
However in that case the rq_xprt_ctxt pointer is NOT cleared so that
when xpo_release_xprt is called, the ctxt is freed (UDP) or possible
added to a free list (RDMA).
When the deferred request is revisited for a second time, it will
reference this ctxt which may be invalid, and the free the object a
second time which is likely to oops.
So change svc_defer() to *always* clear rq_xprt_ctxt, and assert that
the value is now stored in the svc_deferred_req. |
| In the Linux kernel, the following vulnerability has been resolved:
debugobjects: Don't wake up kswapd from fill_pool()
syzbot is reporting a lockdep warning in fill_pool() because the allocation
from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.
Since fill_pool() might be called with arbitrary locks held, fill_pool()
should not assume that acquiring kswapd_wait::lock is safe.
Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
!__GFP_DIRECT_RECLAIM allocation. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will be the same.
vcpudispatch_stats_procfs_init() already works around this by disabling
preemption, but the lparcfg code does not, erroring any time
/proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.
Instead of disabling preemption on the caller side, rework
lppaca_shared_proc() to not take a pointer and instead directly access
the lppaca, bypassing any potential preemption checks.
[mpe: Rework to avoid needing a definition in paca.h and lppaca.h] |
| In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()
'read' is freed when it is known to be NULL, but not when a read error
occurs.
Revert the logic to avoid a small leak, should a m920x_read() call fail. |
