| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: tuners: qt1010: replace BUG_ON with a regular error
BUG_ON is unnecessary here, and in addition it confuses smatch.
Replacing this with an error return help resolve this smatch
warning:
drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34 |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: release path before inode lookup during the ino lookup ioctl
During the ino lookup ioctl we can end up calling btrfs_iget() to get an
inode reference while we are holding on a root's btree. If btrfs_iget()
needs to lookup the inode from the root's btree, because it's not
currently loaded in memory, then it will need to lock another or the
same path in the same root btree. This may result in a deadlock and
trigger the following lockdep splat:
WARNING: possible circular locking dependency detected
6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted
------------------------------------------------------
syz-executor277/5012 is trying to acquire lock:
ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136
but task is already holding lock:
ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{3:3}:
down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645
__btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136
btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302
btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955
btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline]
btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338
btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline]
open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494
btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154
btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519
legacy_get_tree+0xef/0x190 fs/fs_context.c:611
vfs_get_tree+0x8c/0x270 fs/super.c:1519
fc_mount fs/namespace.c:1112 [inline]
vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142
btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579
legacy_get_tree+0xef/0x190 fs/fs_context.c:611
vfs_get_tree+0x8c/0x270 fs/super.c:1519
do_new_mount+0x28f/0xae0 fs/namespace.c:3335
do_mount fs/namespace.c:3675 [inline]
__do_sys_mount fs/namespace.c:3884 [inline]
__se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
-> #0 (btrfs-tree-01){++++}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144
lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645
__btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136
btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline]
btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281
btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline]
btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154
btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412
btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline]
btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716
btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline]
btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105
btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
other info
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: fix potential race when tree connecting ipc
Protect access of TCP_Server_Info::hostname when building the ipc tree
name as it might get freed in cifsd thread and thus causing an
use-after-free bug in __tree_connect_dfs_target(). Also, while at it,
update status of IPC tcon on success and then avoid any extra tree
connects. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix an uninit variable access bug in __ip6_make_skb()
Syzbot reported a bug as following:
=====================================================
BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]
BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]
BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]
BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956
arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]
arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]
atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]
__ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956
ip6_finish_skb include/net/ipv6.h:1122 [inline]
ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987
rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579
rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922
inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476
___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530
__sys_sendmsg net/socket.c:2559 [inline]
__do_sys_sendmsg net/socket.c:2568 [inline]
__se_sys_sendmsg net/socket.c:2566 [inline]
__x64_sys_sendmsg+0x367/0x540 net/socket.c:2566
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook mm/slab.h:766 [inline]
slab_alloc_node mm/slub.c:3452 [inline]
__kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
__do_kmalloc_node mm/slab_common.c:967 [inline]
__kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988
kmalloc_reserve net/core/skbuff.c:492 [inline]
__alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565
alloc_skb include/linux/skbuff.h:1270 [inline]
__ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684
ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854
rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915
inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476
___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530
__sys_sendmsg net/socket.c:2559 [inline]
__do_sys_sendmsg net/socket.c:2568 [inline]
__se_sys_sendmsg net/socket.c:2566 [inline]
__x64_sys_sendmsg+0x367/0x540 net/socket.c:2566
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
It is because icmp6hdr does not in skb linear region under the scenario
of SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly will
trigger the uninit variable access bug.
Use a local variable icmp6_type to carry the correct value in different
scenarios. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/sysv: Null check to prevent null-ptr-deref bug
sb_getblk(inode->i_sb, parent) return a null ptr and taking lock on
that leads to the null-ptr-deref bug. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP
Fixes OOPS on boards with ANX9805 DP encoders. |
