Security Vulnerabilities
- CVEs Published In February 2024
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Free local data after use
Fixes the following memory leak in dc_link_construct():
unreferenced object 0xffffa03e81471400 (size 1024):
comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0
[<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu]
[<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu]
[<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu]
[<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu]
[<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu]
[<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu]
[<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu]
[<00000000fec7d291>] local_pci_probe+0x47/0xa0
[<0000000055dbbfa7>] pci_device_probe+0xe3/0x180
[<00000000815da970>] really_probe+0x1c4/0x4e0
[<00000000b4b6974b>] driver_probe_device+0x62/0x150
[<000000000f9ecc61>] device_driver_attach+0x58/0x60
[<000000000f65c843>] __driver_attach+0xd6/0x150
[<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0
[<00000000a1cfc897>] driver_attach+0x1e/0x20
In the Linux kernel, the following vulnerability has been resolved:
media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
If an error occurs after a successful 'of_icc_get()' call, it must be
undone.
Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak.
Update the remove function accordingly and axe the now unneeded
'icc_put()' calls.
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix shift-out-of-bounds in load_balance()
Syzbot reported a handful of occurrences where an sd->nr_balance_failed can
grow to much higher values than one would expect.
A successful load_balance() resets it to 0; a failed one increments
it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an
active balance, which will either set it to sd->cache_nice_tries+1 or reset
it to 0. However, in case the to-be-active-balanced task is not allowed to
run on env->dst_cpu, then the increment is done without any further
modification.
This could then be repeated ad nauseam, and would explain the absurdly high
values reported by syzbot (86, 149). VincentG noted there is value in
letting sd->cache_nice_tries grow, so the shift itself should be
fixed. That means preventing:
"""
If the value of the right operand is negative or is greater than or equal
to the width of the promoted left operand, the behavior is undefined.
"""
Thus we need to cap the shift exponent to
BITS_PER_TYPE(typeof(lefthand)) - 1.
I had a look around for other similar cases via coccinelle:
@expr@
position pos;
expression E1;
expression E2;
@@
(
E1 >> E2@pos
|
E1 >> E2@pos
)
@cst depends on expr@
position pos;
expression expr.E1;
constant cst;
@@
(
E1 >> cst@pos
|
E1 << cst@pos
)
@script:python depends on !cst@
pos << expr.pos;
exp << expr.E2;
@@
# Dirty hack to ignore constexpr
if exp.upper() != exp:
coccilib.report.print_report(pos[0], "Possible UB shift here")
The only other match in kernel/sched is rq_clock_thermal() which employs
sched_thermal_decay_shift, and that exponent is already capped to 10, so
that one is fine.
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.
Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix off by one in hdmi_14_process_transaction()
The hdcp_i2c_offsets[] array did not have an entry for
HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one
read overflow. I added an entry and copied the 0x0 value for the offset
from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.
I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX
entries. This doesn't change the code, but it's just a belt and
suspenders approach to try future proof the code.
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.
This fixes the following crash which occurs in reading a big block
from flash:
[ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[ 123.792536] Mem abort info:
[ 123.795313] ESR = 0x96000145
[ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits
[ 123.803655] SET = 0, FnV = 0
[ 123.806693] EA = 0, S1PTW = 0
[ 123.809818] Data abort info:
[ 123.812683] ISV = 0, ISS = 0x00000145
[ 123.816503] CM = 1, WnR = 1
[ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
When handling op->addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op->addr.val and op->cmd.opcode to fix
this issue.
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Use after free in __vmbus_open()
The "open_info" variable is added to the &vmbus_connection.chn_msg_list,
but the error handling frees "open_info" without removing it from the
list. This will result in a use after free. First remove it from the
list, and then free it.
In the Linux kernel, the following vulnerability has been resolved:
memory: renesas-rpc-if: fix possible NULL pointer dereference of resource
The platform_get_resource_byname() can return NULL which would be
immediately dereferenced by resource_size(). Instead dereference it
after validating the resource.
Addresses-Coverity: Dereference null return value
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.