| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.
This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and iocost,
but not so for iolatency as it gets initialized before add_disk() is called.
It is desirable to lazy-init rq_qos policies because they are optional
features and add to hot path overhead once initialized - each IO has to walk
all the registered rq_qos policies. So, we want to switch iolatency to lazy
init too. However, that's a bigger change. As a fix for the immediate
problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().
This is safe because duplicate calls to rq_qos_exit() become noop's. |
| In the Linux kernel, the following vulnerability has been resolved:
media: i2c: hi846: Fix memory leak in hi846_parse_dt()
If any of the checks related to the supported link frequencies fail, then
the V4L2 fwnode resources don't get released before returning, which leads
to a memleak. Fix this by properly freeing the V4L2 fwnode data in a
designated label. |
| In the Linux kernel, the following vulnerability has been resolved:
media: solo6x10: fix possible memory leak in solo_sysfs_init()
If device_register() returns error in solo_sysfs_init(), the
name allocated by dev_set_name() need be freed. As comment of
device_register() says, it should use put_device() to give up
the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninititialized value in 'ext4_evict_inode'
Syzbot found the following issue:
=====================================================
BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
evict+0x365/0x9a0 fs/inode.c:664
iput_final fs/inode.c:1747 [inline]
iput+0x985/0xdd0 fs/inode.c:1773
__ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361
ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844
vfs_mknod+0x79d/0x830 fs/namei.c:3914
do_mknodat+0x47d/0xaa0
__do_sys_mknodat fs/namei.c:3992 [inline]
__se_sys_mknodat fs/namei.c:3989 [inline]
__ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989
do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
__do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at:
__alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578
alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285
alloc_slab_page mm/slub.c:1794 [inline]
allocate_slab+0x1b5/0x1010 mm/slub.c:1939
new_slab mm/slub.c:1992 [inline]
___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180
__slab_alloc mm/slub.c:3279 [inline]
slab_alloc_node mm/slub.c:3364 [inline]
slab_alloc mm/slub.c:3406 [inline]
__kmem_cache_alloc_lru mm/slub.c:3413 [inline]
kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429
alloc_inode_sb include/linux/fs.h:3117 [inline]
ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321
alloc_inode+0x83/0x440 fs/inode.c:259
new_inode_pseudo fs/inode.c:1018 [inline]
new_inode+0x3b/0x430 fs/inode.c:1046
__ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959
ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992
vfs_mkdir+0x62a/0x870 fs/namei.c:4035
do_mkdirat+0x466/0x7b0 fs/namei.c:4060
__do_sys_mkdirat fs/namei.c:4075 [inline]
__se_sys_mkdirat fs/namei.c:4073 [inline]
__ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073
do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
__do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
entry_SYSENTER_compat_after_hwframe+0x70/0x82
CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
=====================================================
Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed
before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after
6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which
will lead to access uninit-value.
To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'. |
| In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
[<ffffffff827e20ee>] phy_device_create+0x4e/0x90
[<ffffffff827e6072>] get_phy_device+0xd2/0x220
[<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0
[<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0
[<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]
...
The problem occurs in probe process as follows:
r6040_init_one:
mdiobus_register
mdiobus_scan <- alloc and register phy_device,
the reference count of phy_device is 3
r6040_mii_probe
phy_connect <- connect to the first phy_device,
so the reference count of the first
phy_device is 4, others are 3
register_netdev <- fault inject succeeded, goto error handling path
// error handling path
err_out_mdio_unregister:
mdiobus_unregister(lp->mii_bus);
err_out_mdio:
mdiobus_free(lp->mii_bus); <- the reference count of the first
phy_device is 1, it is not released
and other phy_devices are released
// similarly, the remove process also has the same problem
The root cause is traced to the phy_device is not disconnected when
removes one r6040 device in r6040_remove_one() or on error handling path
after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet
device is connected to the first PHY device of mii_bus, in order to
notify the connected driver when the link status changes, which is the
default behavior of the PHY infrastructure to handle everything.
Therefore the phy_device should be disconnected when removes one r6040
device or on error handling path.
Fix it by adding phy_disconnect() when removes one r6040 device or on
error handling path after r6040_mii probed successfully. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.
We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix mr->map double free
rxe_mr_cleanup() which tries to free mr->map again will be called when
rxe_mr_init_user() fails:
CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x45/0x5d
panic+0x19e/0x349
end_report.part.0+0x54/0x7c
kasan_report.cold+0xa/0xf
rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe]
__rxe_cleanup+0x10a/0x1e0 [rdma_rxe]
rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe]
ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs]
ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]
This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fix
memory leak in error path code") and then we fixed it in commit
8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but this
fix was reverted together at last by commit 1e75550648da (Revert
"RDMA/rxe: Create duplicate mapping tables for FMRs")
Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is
successfully allocated. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow
UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.
These registers are 32-bit hardware counters and the driver uses these
counters to monitor the operational progress status for a channel, when
transferring more than 4GB of data it was observed that these counters
overflow and completion calculation of a operation gets affected and the
transfer hangs indefinitely.
This commit adds changes to decrease the byte count for every complete
transaction so that these registers never overflow and the proper byte
count statistics is maintained for ongoing transaction by the RT counters.
Earlier uc->bcnt used to maintain a count of the completed bytes at driver
side, since the RT counters maintain the statistics of current transaction
now, the maintenance of uc->bcnt is not necessary. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()
In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will
not be freed through rpi_firmware_delete(), fix this leak by calling
kfree() in the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.
We should reset the eval variable to __SK_NONE every time more_data
starts.
This causes:
IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
<TASK>
__tcp_transmit_skb+0xa1b/0xb90
? __alloc_skb+0x8c/0x1a0
? __kmalloc_node_track_caller+0x184/0x320
tcp_write_xmit+0x22a/0x1110
__tcp_push_pending_frames+0x32/0xf0
do_tcp_sendpages+0x62d/0x640
tcp_bpf_push+0xae/0x2c0
tcp_bpf_sendmsg_redir+0x260/0x410
? preempt_count_add+0x70/0xa0
tcp_bpf_send_verdict+0x386/0x4b0
tcp_bpf_sendmsg+0x21b/0x3b0
sock_sendmsg+0x58/0x70
__sys_sendto+0xfa/0x170
? xfd_validate_state+0x1d/0x80
? switch_fpu_return+0x59/0xe0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential null-deref in dm_resume
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
dm thin: Use last transaction's pmd->root when commit failed
Recently we found a softlock up problem in dm thin pool btree lookup
code due to corrupted metadata:
Kernel panic - not syncing: softlockup: hung tasks
CPU: 7 PID: 2669225 Comm: kworker/u16:3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: dm-thin do_worker [dm_thin_pool]
Call Trace:
<IRQ>
dump_stack+0x9c/0xd3
panic+0x35d/0x6b9
watchdog_timer_fn.cold+0x16/0x25
__run_hrtimer+0xa2/0x2d0
</IRQ>
RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]
__bufio_new+0x11f/0x4f0 [dm_bufio]
new_read+0xa3/0x1e0 [dm_bufio]
dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]
ro_step+0x63/0x100 [dm_persistent_data]
btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]
dm_btree_lookup+0x16f/0x210 [dm_persistent_data]
dm_thin_find_block+0x12c/0x210 [dm_thin_pool]
__process_bio_read_only+0xc5/0x400 [dm_thin_pool]
process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]
process_one_work+0x3c5/0x730
Following process may generate a broken btree mixed with fresh and
stale btree nodes, which could get dm thin trapped in an infinite loop
while looking up data block:
Transaction 1: pmd->root = A, A->B->C // One path in btree
pmd->root = X, X->Y->Z // Copy-up
Transaction 2: X,Z is updated on disk, Y write failed.
// Commit failed, dm thin becomes read-only.
process_bio_read_only
dm_thin_find_block
__find_block
dm_btree_lookup(pmd->root)
The pmd->root points to a broken btree, Y may contain stale node
pointing to any block, for example X, which gets dm thin trapped into
a dead loop while looking up Z.
Fix this by setting pmd->root in __open_metadata(), so that dm thin
will use the last transaction's pmd->root if commit failed.
Fetch a reproducer in [Link].
Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()
In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,
sas_rphy_free() needs be called to free the resource allocated in
sas_end_device_alloc(). Otherwise a kernel crash will happen:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x54/0x3d0
lr : device_del+0x37c/0x3d0
Call trace:
device_del+0x54/0x3d0
attribute_container_class_device_del+0x28/0x38
transport_remove_classdev+0x6c/0x80
attribute_container_device_trigger+0x108/0x110
transport_remove_device+0x28/0x38
sas_rphy_remove+0x50/0x78 [scsi_transport_sas]
sas_port_delete+0x30/0x148 [scsi_transport_sas]
do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
device_for_each_child+0x68/0xb0
sas_remove_children+0x30/0x50 [scsi_transport_sas]
sas_rphy_remove+0x38/0x78 [scsi_transport_sas]
sas_port_delete+0x30/0x148 [scsi_transport_sas]
do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
device_for_each_child+0x68/0xb0
sas_remove_children+0x30/0x50 [scsi_transport_sas]
sas_remove_host+0x20/0x38 [scsi_transport_sas]
scsih_remove+0xd8/0x420 [mpt3sas]
Because transport_add_device() is not called when sas_rphy_add() fails, the
device is not added. When sas_rphy_remove() is subsequently called to
remove the device in the remove() path, a NULL pointer dereference happens. |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix an information leak in tipc_topsrv_kern_subscr
Use a 8-byte write to initialize sub.usr_handle in
tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized
when issuing setsockopt(..., SOL_TIPC, ...).
This resulted in an infoleak reported by KMSAN when the packet was
received:
=====================================================
BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169
instrument_copy_to_user ./include/linux/instrumented.h:121
copyout+0xbc/0x100 lib/iov_iter.c:169
_copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527
copy_to_iter ./include/linux/uio.h:176
simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419
skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527
skb_copy_datagram_msg ./include/linux/skbuff.h:3903
packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469
____sys_recvmsg+0x2c4/0x810 net/socket.c:?
___sys_recvmsg+0x217/0x840 net/socket.c:2743
__sys_recvmsg net/socket.c:2773
__do_sys_recvmsg net/socket.c:2783
__se_sys_recvmsg net/socket.c:2780
__x64_sys_recvmsg+0x364/0x540 net/socket.c:2780
do_syscall_x64 arch/x86/entry/common.c:50
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120
...
Uninit was stored to memory at:
tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156
tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375
tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579
tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190
tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084
tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201
__sys_setsockopt+0x87f/0xdc0 net/socket.c:2252
__do_sys_setsockopt net/socket.c:2263
__se_sys_setsockopt net/socket.c:2260
__x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260
do_syscall_x64 arch/x86/entry/common.c:50
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120
Local variable sub created at:
tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562
tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190
Bytes 84-87 of 88 are uninitialized
Memory access of size 88 starts at ffff88801ed57cd0
Data copied to user address 0000000020000400
...
===================================================== |
| In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()
Our syzkaller report a null pointer dereference, root cause is
following:
__blk_mq_alloc_map_and_rqs
set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs
blk_mq_alloc_map_and_rqs
blk_mq_alloc_rqs
// failed due to oom
alloc_pages_node
// set->tags[hctx_idx] is still NULL
blk_mq_free_rqs
drv_tags = set->tags[hctx_idx];
// null pointer dereference is triggered
blk_mq_clear_rq_mapping(drv_tags, ...)
This is because commit 63064be150e4 ("blk-mq:
Add blk_mq_alloc_map_and_rqs()") merged the two steps:
1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()
2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])
into one step:
set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()
Since tags is not initialized yet in this case, fix the problem by
checking if tags is NULL pointer in blk_mq_clear_rq_mapping(). |
| In the Linux kernel, the following vulnerability has been resolved:
test_firmware: fix memory leak in test_firmware_init()
When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config->name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
hex dump (first 32 bytes):
74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
backtrace:
[<ffffffff81b21fcb>] __kmalloc_node_track_caller+0x4b/0xc0
[<ffffffff81affb96>] kstrndup+0x46/0xc0
[<ffffffffa0403a49>] __test_firmware_config_init+0x29/0x380 [test_firmware]
[<ffffffffa040f068>] 0xffffffffa040f068
[<ffffffff81002c41>] do_one_initcall+0x141/0x780
[<ffffffff816a72c3>] do_init_module+0x1c3/0x630
[<ffffffff816adb9e>] load_module+0x623e/0x76a0
[<ffffffff816af471>] __do_sys_finit_module+0x181/0x240
[<ffffffff89978f99>] do_syscall_64+0x39/0xb0
[<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix size validation for non-exclusive domains (v4)
Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the
requested memory exists, else we get a kernel oops when dereferencing "man".
v2: Make the patch standalone, i.e. not dependent on local patches.
v3: Preserve old behaviour and just check that the manager pointer is not
NULL.
v4: Complain if GTT domain requested and it is uninitialized--most likely a
bug. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502664/ |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure
If creation or finalization of a checkpoint fails due to anomalies in the
checkpoint metadata on disk, a kernel warning is generated.
This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted
with panic_on_warn, does not panic. A nilfs_error is appropriate here to
handle the abnormal filesystem condition.
This also replaces the detected error codes with an I/O error so that
neither of the internal error codes is returned to callers. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Check return value after calling platform_get_resource()
platform_get_resource() may return NULL pointer, we need check its
return value to avoid null-ptr-deref in resource_size(). |
