In the Linux kernel, the following vulnerability has been resolved:
wifi: cw1200: Fix potential NULL dereference
A recent refactoring was identified by static analysis to
cause a potential NULL dereference, fix this! |
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()
kmalloc may fail, return value might be NULL and will cause
NULL pointer derefe...Show moreIn the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()
kmalloc may fail, return value might be NULL and will cause
NULL pointer dereference. Add check NULL return of kmalloc in
btc_fw_set_monreg().Show less |
In the Linux kernel, the following vulnerability has been resolved:
isofs: avoid memory leak in iocharset
A memleak was found as below:
unreferenced object 0xffff0000d10164d8 (size 8):
comm "pool-udisksd", pid 10821...Show moreIn the Linux kernel, the following vulnerability has been resolved:
isofs: avoid memory leak in iocharset
A memleak was found as below:
unreferenced object 0xffff0000d10164d8 (size 8):
comm "pool-udisksd", pid 108217, jiffies 4295408555
hex dump (first 8 bytes):
75 74 66 38 00 cc cc cc utf8....
backtrace (crc de430d31):
[<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8
[<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474
[<ffff800080363b74>] kstrdup+0x70/0xfc
[<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs]
[<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164
[<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4
[<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc
[<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c
[<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c
[<ffff8000804b6a64>] path_mount+0x6c4/0x9ec
[<ffff8000804b6e38>] do_mount+0xac/0xc4
[<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0
[<ffff80008002b8dc>] invoke_syscall+0x7c/0x104
[<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104
[<ffff80008002ba94>] do_el0_svc+0x2c/0x38
[<ffff800081041108>] el0_svc+0x3c/0x1b8
The opt->iocharset is freed inside the isofs_fill_super function,
But there may be situations where it's not possible to
enter this function.
For example, in the get_tree_bdev_flags function,when
encountering the situation where "Can't mount, would change RO state,"
In such a case, isofs_fill_super will not have the opportunity
to be called,which means that opt->iocharset will not have the chance
to be freed,ultimately leading to a memory leak.
Let's move the memory freeing of opt->iocharset into
isofs_free_fc function.Show less |
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the...Show moreIn the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.Show less |
In the Linux kernel, the following vulnerability has been resolved:
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, th...Show moreIn the Linux kernel, the following vulnerability has been resolved:
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
The loop of us122l->mmap_count check is dropped as well. The check is
useless for the asynchronous operation with *_when_closed().Show less |
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the...Show moreIn the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
This patch also splits the code to the disconnect and the free phases;
the former is called immediately at the USB disconnect callback while
the latter is called from the card destructor.Show less |
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort(). B...Show moreIn the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort(). But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).
For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback.Show less |
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtk: adjust the position to init iso data anchor
MediaTek iso data anchor init should be moved to where MediaTek
claims iso data interfac...Show moreIn the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtk: adjust the position to init iso data anchor
MediaTek iso data anchor init should be moved to where MediaTek
claims iso data interface.
If there is an unexpected BT usb disconnect during setup flow,
it will cause a NULL pointer crash issue when releasing iso
anchor since the anchor wasn't been init yet. Adjust the position
to do iso data anchor init.
[ 17.137991] pc : usb_kill_anchored_urbs+0x60/0x168
[ 17.137998] lr : usb_kill_anchored_urbs+0x44/0x168
[ 17.137999] sp : ffffffc0890cb5f0
[ 17.138000] x29: ffffffc0890cb5f0 x28: ffffff80bb6c2e80
[ 17.144081] gpio gpiochip0: registered chardev handle for 1 lines
[ 17.148421] x27: 0000000000000000
[ 17.148422] x26: ffffffd301ff4298 x25: 0000000000000003 x24: 00000000000000f0
[ 17.148424] x23: 0000000000000000 x22: 00000000ffffffff x21: 0000000000000001
[ 17.148425] x20: ffffffffffffffd8 x19: ffffff80c0f25560 x18: 0000000000000000
[ 17.148427] x17: ffffffd33864e408 x16: ffffffd33808f7c8 x15: 0000000000200000
[ 17.232789] x14: e0cd73cf80ffffff x13: 50f2137c0a0338c9 x12: 0000000000000001
[ 17.239912] x11: 0000000080150011 x10: 0000000000000002 x9 : 0000000000000001
[ 17.247035] x8 : 0000000000000000 x7 : 0000000000008080 x6 : 8080000000000000
[ 17.254158] x5 : ffffffd33808ebc0 x4 : fffffffe033dcf20 x3 : 0000000080150011
[ 17.261281] x2 : ffffff8087a91400 x1 : 0000000000000000 x0 : ffffff80c0f25588
[ 17.268404] Call trace:
[ 17.270841] usb_kill_anchored_urbs+0x60/0x168
[ 17.275274] btusb_mtk_release_iso_intf+0x2c/0xd8 [btusb (HASH:5afe 6)]
[ 17.284226] btusb_mtk_disconnect+0x14/0x28 [btusb (HASH:5afe 6)]
[ 17.292652] btusb_disconnect+0x70/0x140 [btusb (HASH:5afe 6)]
[ 17.300818] usb_unbind_interface+0xc4/0x240
[ 17.305079] device_release_driver_internal+0x18c/0x258
[ 17.310296] device_release_driver+0x1c/0x30
[ 17.314557] bus_remove_device+0x140/0x160
[ 17.318643] device_del+0x1c0/0x330
[ 17.322121] usb_disable_device+0x80/0x180
[ 17.326207] usb_disconnect+0xec/0x300
[ 17.329948] hub_quiesce+0x80/0xd0
[ 17.333339] hub_disconnect+0x44/0x190
[ 17.337078] usb_unbind_interface+0xc4/0x240
[ 17.341337] device_release_driver_internal+0x18c/0x258
[ 17.346551] device_release_driver+0x1c/0x30
[ 17.350810] usb_driver_release_interface+0x70/0x88
[ 17.355677] proc_ioctl+0x13c/0x228
[ 17.359157] proc_ioctl_default+0x50/0x80
[ 17.363155] usbdev_ioctl+0x830/0xd08
[ 17.366808] __arm64_sys_ioctl+0x94/0xd0
[ 17.370723] invoke_syscall+0x6c/0xf8
[ 17.374377] el0_svc_common+0x84/0xe0
[ 17.378030] do_el0_svc+0x20/0x30
[ 17.381334] el0_svc+0x34/0x60
[ 17.384382] el0t_64_sync_handler+0x88/0xf0
[ 17.388554] el0t_64_sync+0x180/0x188
[ 17.392208] Code: f9400677 f100a2f4 54fffea0 d503201f (b8350288)
[ 17.398289] ---[ end trace 0000000000000000 ]---Show less |
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix use-after-free in device_for_each_child()
Syzbot has reported the following KASAN splat:
BUG: KASAN: slab-use-after-free in device_for...Show moreIn the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix use-after-free in device_for_each_child()
Syzbot has reported the following KASAN splat:
BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0
Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980
CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x100/0x190
? device_for_each_child+0x18f/0x1a0
print_report+0x13a/0x4cb
? __virt_addr_valid+0x5e/0x590
? __phys_addr+0xc6/0x150
? device_for_each_child+0x18f/0x1a0
kasan_report+0xda/0x110
? device_for_each_child+0x18f/0x1a0
? __pfx_dev_memalloc_noio+0x10/0x10
device_for_each_child+0x18f/0x1a0
? __pfx_device_for_each_child+0x10/0x10
pm_runtime_set_memalloc_noio+0xf2/0x180
netdev_unregister_kobject+0x1ed/0x270
unregister_netdevice_many_notify+0x123c/0x1d80
? __mutex_trylock_common+0xde/0x250
? __pfx_unregister_netdevice_many_notify+0x10/0x10
? trace_contention_end+0xe6/0x140
? __mutex_lock+0x4e7/0x8f0
? __pfx_lock_acquire.part.0+0x10/0x10
? rcu_is_watching+0x12/0xc0
? unregister_netdev+0x12/0x30
unregister_netdevice_queue+0x30d/0x3f0
? __pfx_unregister_netdevice_queue+0x10/0x10
? __pfx_down_write+0x10/0x10
unregister_netdev+0x1c/0x30
bnep_session+0x1fb3/0x2ab0
? __pfx_bnep_session+0x10/0x10
? __pfx_lock_release+0x10/0x10
? __pfx_woken_wake_function+0x10/0x10
? __kthread_parkme+0x132/0x200
? __pfx_bnep_session+0x10/0x10
? kthread+0x13a/0x370
? __pfx_bnep_session+0x10/0x10
kthread+0x2b7/0x370
? __pfx_kthread+0x10/0x10
ret_from_fork+0x48/0x80
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 4974:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
__kmalloc_noprof+0x1d1/0x440
hci_alloc_dev_priv+0x1d/0x2820
__vhci_create_device+0xef/0x7d0
vhci_write+0x2c7/0x480
vfs_write+0x6a0/0xfc0
ksys_write+0x12f/0x260
do_syscall_64+0xc7/0x250
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 4979:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x4f/0x70
kfree+0x141/0x490
hci_release_dev+0x4d9/0x600
bt_host_release+0x6a/0xb0
device_release+0xa4/0x240
kobject_put+0x1ec/0x5a0
put_device+0x1f/0x30
vhci_release+0x81/0xf0
__fput+0x3f6/0xb30
task_work_run+0x151/0x250
do_exit+0xa79/0x2c30
do_group_exit+0xd5/0x2a0
get_signal+0x1fcd/0x2210
arch_do_signal_or_restart+0x93/0x780
syscall_exit_to_user_mode+0x140/0x290
do_syscall_64+0xd4/0x250
entry_SYSCALL_64_after_hwframe+0x77/0x7f
In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when
an underlying (kobject) reference counter is greater than 1. This
means that reparenting (happened when the device is actually freed)
is delayed and, during that delay, parent controller device (hciX)
may be deleted. Since the latter may create a dangling pointer to
freed parent, avoid that scenario by reparenting to NULL explicitly.Show less |
In the Linux kernel, the following vulnerability has been resolved:
xsk: Free skb when TX metadata options are invalid
When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descri...Show moreIn the Linux kernel, the following vulnerability has been resolved:
xsk: Free skb when TX metadata options are invalid
When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descriptor or the first frag of a multibuf descriptor,
but the descriptor is later found to have invalid options set for the TX
metadata, the new skb is never freed. This can leak skbs until the send
buffer is full which makes sending more packets impossible.
Fix this by freeing the skb in the error path if we are currently dealing
with the first frag, i.e., an skb allocated in this iteration of
xsk_build_skb.Show less |
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix file-backed mounts over FUSE
syzbot reported a null-ptr-deref in fuse_read_args_fill:
fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905
filem...Show moreIn the Linux kernel, the following vulnerability has been resolved:
erofs: fix file-backed mounts over FUSE
syzbot reported a null-ptr-deref in fuse_read_args_fill:
fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905
filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367
do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825
read_mapping_folio include/linux/pagemap.h:1011 [inline]
erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41
erofs_read_superblock fs/erofs/super.c:281 [inline]
erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625
Unlike most filesystems, some network filesystems and FUSE need
unavoidable valid `file` pointers for their read I/Os [1].
Anyway, those use cases need to be supported too.
[1] https://docs.kernel.org/filesystems/vfs.htmlShow less |
In the Linux kernel, the following vulnerability has been resolved:
erofs: handle NONHEAD !delta[1] lclusters gracefully
syzbot reported a WARNING in iomap_iter_done:
iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80
ioc...Show moreIn the Linux kernel, the following vulnerability has been resolved:
erofs: handle NONHEAD !delta[1] lclusters gracefully
syzbot reported a WARNING in iomap_iter_done:
iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80
ioctl_fiemap fs/ioctl.c:220 [inline]
Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted
images and filesystems created by pre-1.0 mkfs versions.
Previously, it would immediately bail out if delta[1]==0, which led to
inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as
delta[1]=1 to work around these legacy mkfs versions.
`lclusterbits > 14` is illegal for compact indexes, error out too.Show less |
In the Linux kernel, the following vulnerability has been resolved:
unicode: Fix utf8_load() error path
utf8_load() requests the symbol "utf8_data_table" and then checks if the
requested UTF-8 version is supported. If...Show moreIn the Linux kernel, the following vulnerability has been resolved:
unicode: Fix utf8_load() error path
utf8_load() requests the symbol "utf8_data_table" and then checks if the
requested UTF-8 version is supported. If it's unsupported, it tries to
put the data table using symbol_put(). If an unsupported version is
requested, symbol_put() fails like this:
kernel BUG at kernel/module/main.c:786!
RIP: 0010:__symbol_put+0x93/0xb0
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? die+0x2e/0x50
? do_trap+0xca/0x110
? do_error_trap+0x65/0x80
? __symbol_put+0x93/0xb0
? exc_invalid_op+0x51/0x70
? __symbol_put+0x93/0xb0
? asm_exc_invalid_op+0x1a/0x20
? __pfx_cmp_name+0x10/0x10
? __symbol_put+0x93/0xb0
? __symbol_put+0x62/0xb0
utf8_load+0xf8/0x150
That happens because symbol_put() expects the unique string that
identify the symbol, instead of a pointer to the loaded symbol. Fix that
by using such string.Show less |
In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Implement blocking domain
This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iom...Show moreIn the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Implement blocking domain
This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling. With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.Show less |
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()
cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask...Show moreIn the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()
cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask and it will cause null pointer dereference.Show less |
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()
cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask an...Show moreIn the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()
cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask and it will cause null pointer dereference,
so check NULL for cppc_get_cpu_cost().Show less |
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be
set to error. Or else the followin...Show moreIn the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be
set to error. Or else the following will appear.
[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6
[ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65
[ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24
[ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246
[ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008
[ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac
[ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450
[ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800
[ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000
[ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000
[ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0
[ 920.623680] Call Trace:
[ 920.623815] <TASK>
[ 920.623933] ? __warn+0x79/0xc0
[ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.624356] ? report_bug+0xfb/0x150
[ 920.624594] ? handle_bug+0x3c/0x60
[ 920.624796] ? exc_invalid_op+0x14/0x70
[ 920.624976] ? asm_exc_invalid_op+0x16/0x20
[ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe]
[ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe]
[ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe]
[ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe]
[ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe]
[ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]
[ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe]
[ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120
[ 920.627522] handle_softirqs+0xc2/0x250
[ 920.627728] ? sort_range+0x20/0x20
[ 920.627942] run_ksoftirqd+0x1f/0x30
[ 920.628158] smpboot_thread_fn+0xc7/0x1b0
[ 920.628334] kthread+0xd6/0x100
[ 920.628504] ? kthread_complete_and_exit+0x20/0x20
[ 920.628709] ret_from_fork+0x1f/0x30
[ 920.628892] </TASK>Show less |
In the Linux kernel, the following vulnerability has been resolved:
riscv: kvm: Fix out-of-bounds array access
In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an
out-of-bound index. This is used as a specia...Show moreIn the Linux kernel, the following vulnerability has been resolved:
riscv: kvm: Fix out-of-bounds array access
In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an
out-of-bound index. This is used as a special marker for the base
extensions, that cannot be disabled. However, when traversing the
extensions, that special marker is not checked prior indexing the
array.
Add an out-of-bounds check to the function.Show less |
In the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Fix use-after-free in bfad_im_module_exit()
BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
Read of size 8 at addr ffff8881...Show moreIn the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Fix use-after-free in bfad_im_module_exit()
BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303
Call Trace:
<TASK>
dump_stack_lvl+0x95/0xe0
print_report+0xcb/0x620
kasan_report+0xbd/0xf0
__lock_acquire+0x2aca/0x3a20
lock_acquire+0x19b/0x520
_raw_spin_lock+0x2b/0x40
attribute_container_unregister+0x30/0x160
fc_release_transport+0x19/0x90 [scsi_transport_fc]
bfad_im_module_exit+0x23/0x60 [bfa]
bfad_init+0xdb/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 25303:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x7f/0x90
fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]
bfad_im_module_init+0x17/0x80 [bfa]
bfad_init+0x23/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 25303:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x38/0x50
kfree+0x212/0x480
bfad_im_module_init+0x7e/0x80 [bfa]
bfad_init+0x23/0xff0 [bfa]
do_one_initcall+0xdc/0x550
do_init_module+0x22d/0x6b0
load_module+0x4e96/0x5ff0
init_module_from_file+0xcd/0x130
idempotent_init_module+0x330/0x620
__x64_sys_finit_module+0xb3/0x110
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Above issue happens as follows:
bfad_init
error = bfad_im_module_init()
fc_release_transport(bfad_im_scsi_transport_template);
if (error)
goto ext;
ext:
bfad_im_module_exit();
fc_release_transport(bfad_im_scsi_transport_template);
--> Trigger double release
Don't call bfad_im_module_exit() if bfad_im_module_init() failed.Show less |
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.
The driver needs t...Show moreIn the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.
The driver needs to check whether it is a NULL pointer before
dereferencing it.Show less |