| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &com.cmd.ConfigureBuffers.config,
when calling memcpy().
This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy(). |
| In the Linux kernel, the following vulnerability has been resolved:
driver core: auxiliary bus: Fix memory leak when driver_register() fail
If driver_register() returns with error we need to free the memory
allocated for auxdrv->driver.name before returning from
__auxiliary_driver_register() |
| In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: core: Validate channel ID when processing command completions
MHI reads the channel ID from the event ring element sent by the
device which can be any value between 0 and 255. In order to
prevent any out of bound accesses, add a check against the maximum
number of channels supported by the controller and those channels
not configured yet so as to skip processing of that event ring
element. |
| In the Linux kernel, the following vulnerability has been resolved:
net:sfc: fix non-freed irq in legacy irq mode
SFC driver can be configured via modparam to work using MSI-X, MSI or
legacy IRQ interrupts. In the last one, the interrupt was not properly
released on module remove.
It was not freed because the flag irqs_hooked was not set during
initialization in the case of using legacy IRQ.
Example of (trimmed) trace during module remove without this fix:
remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1'
WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170
...trimmed...
Call Trace:
unregister_irq_proc+0xe3/0x100
free_desc+0x29/0x70
irq_free_descs+0x47/0x70
mp_unmap_irq+0x58/0x60
acpi_unregister_gsi_ioapic+0x2a/0x40
acpi_pci_irq_disable+0x78/0xb0
pci_disable_device+0xd1/0x100
efx_pci_remove+0xa1/0x1e0 [sfc]
pci_device_remove+0x38/0xa0
__device_release_driver+0x177/0x230
driver_detach+0xcb/0x110
bus_remove_driver+0x58/0xd0
pci_unregister_driver+0x2a/0xb0
efx_exit_module+0x24/0xf40 [sfc]
__do_sys_delete_module.constprop.0+0x171/0x280
? exit_to_user_mode_prepare+0x83/0x1d0
do_syscall_64+0x3d/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f9f9385800b
...trimmed... |
| In the Linux kernel, the following vulnerability has been resolved:
spi: bcm2835: Fix out-of-bounds access with more than 4 slaves
Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for
->prepare_message()") limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.
The commit sought to enforce the limitation at run-time by setting the
controller's num_chipselect to 3: Slaves with a higher chipselect are
rejected by spi_add_device().
However the commit neglected that num_chipselect only limits the number
of *native* chipselects. If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].
As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which "ought to be enough for anybody"), enforce
the limitation on slave ->setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix race of snd_seq_timer_open()
The timer instance per queue is exclusive, and snd_seq_timer_open()
should have managed the concurrent accesses. It looks as if it's
checking the already existing timer instance at the beginning, but
it's not right, because there is no protection, hence any later
concurrent call of snd_seq_timer_open() may override the timer
instance easily. This may result in UAF, as the leftover timer
instance can keep running while the queue itself gets closed, as
spotted by syzkaller recently.
For avoiding the race, add a proper check at the assignment of
tmr->timeri again, and return -EBUSY if it's been already registered. |
| In the Linux kernel, the following vulnerability has been resolved:
drm: Fix use-after-free read in drm_getunique()
There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.
An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.
To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value. |
| In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()
This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself. |
| In the Linux kernel, the following vulnerability has been resolved:
kvm: avoid speculation-based attacks from out-of-range memslot accesses
KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot. The translation is
performed in __gfn_to_hva_memslot using the following formula:
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
It is expected that gfn falls within the boundaries of the guest's
physical memory. However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva. If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.
Right now it's not clear if there are any cases in which this is
exploitable. One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86. Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier. However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space. Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets. Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached. This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Do not blindly read the ip address in ftrace_bug()
It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.
Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing: Correct the length check which causes memory corruption
We've suffered from severe kernel crashes due to memory corruption on
our production environment, like,
Call Trace:
[1640542.554277] general protection fault: 0000 [#1] SMP PTI
[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
0000000006e931bf
[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
ffff9a45ff004300
[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
0000000000000000
[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffff9a20608d
[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
696c662f65636976
[1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
knlGS:0000000000000000
[1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
00000000003606e0
[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[1640542.566742] Call Trace:
[1640542.567009] anon_vma_clone+0x5d/0x170
[1640542.567417] __split_vma+0x91/0x1a0
[1640542.567777] do_munmap+0x2c6/0x320
[1640542.568128] vm_munmap+0x54/0x70
[1640542.569990] __x64_sys_munmap+0x22/0x30
[1640542.572005] do_syscall_64+0x5b/0x1b0
[1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1640542.575642] RIP: 0033:0x7f45d6e61e27
James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[ 86.780806] no_context+0xdf/0x3c0
[ 86.784327] __do_page_fault+0x252/0x470
[ 86.788367] do_page_fault+0x32/0x140
[ 86.792145] page_fault+0x1e/0x30
[ 86.795576] strncpy_from_unsafe+0x66/0xb0
[ 86.799789] fetch_memory_string+0x25/0x40
[ 86.804002] fetch_deref_string+0x51/0x60
[ 86.808134] kprobe_trace_func+0x32d/0x3a0
[ 86.812347] kprobe_dispatcher+0x45/0x50
[ 86.816385] kprobe_ftrace_handler+0x90/0xf0
[ 86.820779] ftrace_ops_assist_func+0xa1/0x140
[ 86.825340] 0xffffffffc00750bf
[ 86.828603] do_sys_open+0x5/0x1f0
[ 86.832124] do_syscall_64+0x5b/0x1b0
[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9
commit b220c049d519 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry->array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled
When only PHY1 is used (for example on Odroid-HC4), the regmap init code
uses the usb2 ports when doesn't initialize the PHY1 regmap entry.
This fixes:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
pc : regmap_update_bits_base+0x40/0xa0
lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8
...
Call trace:
regmap_update_bits_base+0x40/0xa0
dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8
dwc3_meson_g12a_usb2_init+0x7c/0xc8
dwc3_meson_g12a_usb_init+0x28/0x48
dwc3_meson_g12a_probe+0x298/0x540
platform_probe+0x70/0xe0
really_probe+0xf0/0x4d8
driver_probe_device+0xfc/0x168
... |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL
There exists a possible scenario in which dwc3_gadget_init() can fail:
during during host -> peripheral mode switch in dwc3_set_mode(), and
a pending gadget driver fails to bind. Then, if the DRD undergoes
another mode switch from peripheral->host the resulting
dwc3_gadget_exit() will attempt to reference an invalid and dangling
dwc->gadget pointer as well as call dma_free_coherent() on unmapped
DMA pointers.
The exact scenario can be reproduced as follows:
- Start DWC3 in peripheral mode
- Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)
- Run FunctionFS userspace application (open EPs, write descriptors, etc)
- Bind gadget driver to DWC3's UDC
- Switch DWC3 to host mode
=> dwc3_gadget_exit() is called. usb_del_gadget() will put the
ConfigFS driver instance on the gadget_driver_pending_list
- Stop FunctionFS application (closes the ep files)
- Switch DWC3 to peripheral mode
=> dwc3_gadget_init() fails as usb_add_gadget() calls
check_pending_gadget_drivers() and attempts to rebind the UDC
to the ConfigFS gadget but fails with -19 (-ENODEV) because the
FFS instance is not in FFS_ACTIVE state (userspace has not
re-opened and written the descriptors yet, i.e. desc_ready!=0).
- Switch DWC3 back to host mode
=> dwc3_gadget_exit() is called again, but this time dwc->gadget
is invalid.
Although it can be argued that userspace should take responsibility
for ensuring that the FunctionFS application be ready prior to
allowing the composite driver bind to the UDC, failure to do so
should not result in a panic from the kernel driver.
Fix this by setting dwc->gadget to NULL in the failure path of
dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out
unless the gadget pointer is valid. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler
Patch fixes the following critical issue caused by deadlock which has been
detected during testing NCM class:
smp: csd: Detected non-responsive CSD lock (#1) on CPU#0
smp: csd: CSD lock (#1) unresponsive.
....
RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0
RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002
RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658
RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000
R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658
R13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0
Call Trace:
<IRQ>
do_raw_spin_lock+0xc0/0xd0
_raw_spin_lock_irqsave+0x95/0xa0
cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]
usb_ep_queue+0x35/0x110
eth_start_xmit+0x220/0x3d0 [u_ether]
ncm_tx_timeout+0x34/0x40 [usb_f_ncm]
? ncm_free_inst+0x50/0x50 [usb_f_ncm]
__hrtimer_run_queues+0xac/0x440
hrtimer_run_softirq+0x8c/0xb0
__do_softirq+0xcf/0x428
asm_call_irq_on_stack+0x12/0x20
</IRQ>
do_softirq_own_stack+0x61/0x70
irq_exit_rcu+0xc1/0xd0
sysvec_apic_timer_interrupt+0x52/0xb0
asm_sysvec_apic_timer_interrupt+0x12/0x20
RIP: 0010:do_raw_spin_trylock+0x18/0x40
RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658
RBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000
R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658
R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000
_raw_spin_lock+0x3d/0x70
? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]
cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]
? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]
? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]
? irq_thread+0xa0/0x1c0
irq_thread_fn+0x28/0x60
irq_thread+0x105/0x1c0
? __kthread_parkme+0x42/0x90
? irq_forced_thread_fn+0x90/0x90
? wake_threads_waitq+0x30/0x30
? irq_thread_check_affinity+0xe0/0xe0
kthread+0x12a/0x160
? kthread_park+0x90/0x90
ret_from_fork+0x22/0x30
The root cause of issue is spin_lock/spin_unlock instruction instead
spin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler
function. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: fix various gadgets null ptr deref on 10gbps cabling.
This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: ep0: fix NULL pointer exception
There is no validation of the index from dwc3_wIndex_to_dep() and we might
be referring a non-existing ep and trigger a NULL pointer exception. In
certain configurations we might use fewer eps and the index might wrongly
indicate a larger ep index than existing.
By adding this validation from the patch we can actually report a wrong
index back to the caller.
In our usecase we are using a composite device on an older kernel, but
upstream might use this fix also. Unfortunately, I cannot describe the
hardware for others to reproduce the issue as it is a proprietary
implementation.
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4
[ 82.966891] Mem abort info:
[ 82.969663] ESR = 0x96000006
[ 82.972703] Exception class = DABT (current EL), IL = 32 bits
[ 82.978603] SET = 0, FnV = 0
[ 82.981642] EA = 0, S1PTW = 0
[ 82.984765] Data abort info:
[ 82.987631] ISV = 0, ISS = 0x00000006
[ 82.991449] CM = 0, WnR = 0
[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000
[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)
[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
...
[ 83.141788] Call trace:
[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c
[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94
[ 83.181546] ---[ end trace aac6b5267d84c32f ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port
A pending hrtimer may expire after the kthread_worker of tcpm port
is destroyed, see below kernel dump when do module unload, fix it
by cancel the 2 hrtimers.
[ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880
[ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 111.526594] Mem abort info:
[ 111.526597] ESR = 0x96000047
[ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits
[ 111.526604] SET = 0, FnV = 0
[ 111.526607] EA = 0, S1PTW = 0
[ 111.526610] Data abort info:
[ 111.526612] ISV = 0, ISS = 0x00000047
[ 111.526615] CM = 0, WnR = 1
[ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000
[ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000
[ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP
[ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci]
[ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36
[ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT)
[ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--)
[ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390
[ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4
[ 111.526703] sp : ffff800010003e20
[ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180
[ 111.537156] buffer_io_error: 6 callbacks suppressed
[ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read
[ 111.539932] x27: ffff00017f3801c0
[ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001
[ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0
[ 111.548304]
[ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180
[ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read
[ 111.554499]
[ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000
[ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read
[ 111.561218]
[ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read
[ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040
[ 111.570902] x11: ffff0000c05ac6d8
[ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read
[ 111.588978] x10: 0000000000000000 x9 : 0000000000040000
[ 111.588988] x8 : 0000000000000000
[ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read
[ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880
[ 111.605777] x5 : ffff00017f384880
[ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read
[ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184
[ 111.617096] x2 : ffff8000118cb880
[ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read
[ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888
[ 111.626938] Call trace:
[ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390
[ 111.795809] kthread_queue_work+0x30/0xc0
[ 111.799828] state_machine_timer_handler+0x20/0x30
[ 111.804624] __hrtimer_run_queues+0x140/0x1e0
[ 111.808990] hrtimer_interrupt+0xec/0x2c0
[ 111.813004] arch_timer_handler_phys+0x38/0x50
[ 111.817456] handle_percpu_devid_irq+0x88/0x150
[ 111.821991] __handle_domain_irq+0x80/0xe0
[ 111.826093] gic_handle_irq+0xc0/0x140
[ 111.829848] el1_irq+0xbc/0x154
[ 111.832991] arch_cpu_idle+0x1c/0x2c
[ 111.836572] default_idle_call+0x24/0x6c
[ 111.840497] do_idle+0x238/0x2ac
[ 1
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer
needed validation by the driver. The missing check in the mlx5_ib driver
could cause to the below oops.
Call trace:
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
do_vfs_ioctl+0xd0/0xaf0
ksys_ioctl+0x84/0xb4
__arm64_sys_ioctl+0x28/0xc4
el0_svc_common.constprop.3+0xa4/0x254
el0_svc_handler+0x84/0xa0
el0_svc+0x10/0x26c
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a) |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix Null-point-dereference in fmt_single_name()
Check the return value of devm_kstrdup() in case of
Null-point-dereference. |
