| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/stm: ltdc: fix late dereference check
In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a
container_of() before the pointer check. This could cause a kernel panic.
Fix this smatch warning:
drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.
OpenBSD has been doing it like this from the beginning, so this should
work on all chips.
Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device. |
| 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:
md: raid1: fix potential OOB in raid1_remove_disk()
If rddev->raid_disk is greater than mddev->raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:
1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")
Fix this bug by checking whether the "number" variable is
valid. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend
sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,
driver unconditionally disables ecc_irq which is only enabled on
those asics enabling sdma ecc. This will introduce a warning in
suspend cycle on those chips with sdma ip v4.0, while without
sdma ecc. So this patch correct this.
[ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246
[ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000
[ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000
[ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006
[ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390
[ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
[ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
[ 7283.167041] Call Trace:
[ 7283.167046] <TASK>
[ 7283.167048] sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]
[ 7283.167704] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
[ 7283.168296] amdgpu_device_suspend+0x103/0x180 [amdgpu]
[ 7283.168875] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
[ 7283.169464] pci_pm_freeze+0x54/0xc0 |
| In the Linux kernel, the following vulnerability has been resolved:
posix-timers: Ensure timer ID search-loop limit is valid
posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.
This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.
But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:
CPU0 CPU1
posix_timer_add()
start = sig->posix_timer_id;
lock(hash_lock);
... posix_timer_add()
if (++sig->posix_timer_id < 0)
start = sig->posix_timer_id;
sig->posix_timer_id = 0;
So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:
if (sig->posix_timer_id == start)
break;
While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.
Rewrite it so that all id operations are under the hash lock. |
| 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:
soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe
wkup_m3_ipc_get() takes refcount, which should be freed by
wkup_m3_ipc_put(). Add missing refcount release in the error paths. |
| In the Linux kernel, the following vulnerability has been resolved:
kcsan: Avoid READ_ONCE() in read_instrumented_memory()
Haibo Li reported:
| Unable to handle kernel paging request at virtual address
| ffffff802a0d8d7171
| Mem abort info:o:
| ESR = 0x9600002121
| EC = 0x25: DABT (current EL), IL = 32 bitsts
| SET = 0, FnV = 0 0
| EA = 0, S1PTW = 0 0
| FSC = 0x21: alignment fault
| Data abort info:o:
| ISV = 0, ISS = 0x0000002121
| CM = 0, WnR = 0 0
| swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000
| [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003,
| pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707
| Internal error: Oops: 96000021 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted
| 5.15.78-android13-8-g63561175bbda-dirty #1
| ...
| pc : kcsan_setup_watchpoint+0x26c/0x6bc
| lr : kcsan_setup_watchpoint+0x88/0x6bc
| sp : ffffffc00ab4b7f0
| x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001
| x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80
| x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71
| x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060
| x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000
| x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0
| x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8
| x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007
| x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70
| x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000
| Call trace:
| kcsan_setup_watchpoint+0x26c/0x6bc
| __tsan_read2+0x1f0/0x234
| inflate_fast+0x498/0x750
| zlib_inflate+0x1304/0x2384
| __gunzip+0x3a0/0x45c
| gunzip+0x20/0x30
| unpack_to_rootfs+0x2a8/0x3fc
| do_populate_rootfs+0xe8/0x11c
| async_run_entry_fn+0x58/0x1bc
| process_one_work+0x3ec/0x738
| worker_thread+0x4c4/0x838
| kthread+0x20c/0x258
| ret_from_fork+0x10/0x20
| Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) )
| ---[ end trace 613a943cb0a572b6 ]-----
The reason for this is that on certain arm64 configuration since
e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire
instruction which cannot be used on unaligned addresses.
Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply
forcing the compiler to do the required access by casting to the
appropriate volatile type. In terms of generated code this currently
only affects architectures that do not use the default READ_ONCE()
implementation.
The only downside is that we are not guaranteed atomicity of the access
itself, although on most architectures a plain load up to machine word
size should still be atomic (a fact the default READ_ONCE() still relies
on itself). |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Free released resource after coalescing
release_resource() doesn't actually free the resource or resource list
entry so free the resource list entry to avoid a leak. |
| In the Linux kernel, the following vulnerability has been resolved:
um: vector: Fix memory leak in vector_config
If the return value of the uml_parse_vector_ifspec function is NULL,
we should call kfree(params) to prevent memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: fix memory leak in vfio_ap device driver
The device release callback function invoked to release the matrix device
uses the dev_get_drvdata(device *dev) function to retrieve the
pointer to the vfio_matrix_dev object in order to free its storage. The
problem is, this object is not stored as drvdata with the device; since the
kfree function will accept a NULL pointer, the memory for the
vfio_matrix_dev object is never freed.
Since the device being released is contained within the vfio_matrix_dev
object, the container_of macro will be used to retrieve its pointer. |
| 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:
irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probe
of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak. |
| 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:
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:
scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()
When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4)
returns false, drbl_regs_memmap_p is not remapped. This passes a NULL
pointer to iounmap(), which can trigger a WARN() on certain arches.
When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4)
returns true, drbl_regs_memmap_p may has been remapped and
ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a
NULL pointer to iounmap().
To fix these issues, we need to add null checks before iounmap(), and
change some goto labels. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ptdma: check for null desc before calling pt_cmd_callback
Resolves a panic that can occur on AMD systems, typically during host
shutdown, after the PTDMA driver had been exercised. The issue was
the pt_issue_pending() function is mistakenly assuming that there will
be at least one descriptor in the Submitted queue when the function
is called. However, it is possible that both the Submitted and Issued
queues could be empty, which could result in pt_cmd_callback() being
mistakenly called with a NULL pointer.
Ref: Bugzilla Bug 216856. |
