| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
Hulk Robot reported a panic in put_page_testzero() when testing
madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying
get_any_page(). This is because we keep MF_COUNT_INCREASED flag in
second try but the refcnt is not increased.
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
------------[ cut here ]------------
kernel BUG at include/linux/mm.h:737!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: release_pages+0x53f/0x840
Call Trace:
free_pages_and_swap_cache+0x64/0x80
tlb_flush_mmu+0x6f/0x220
unmap_page_range+0xe6c/0x12c0
unmap_single_vma+0x90/0x170
unmap_vmas+0xc4/0x180
exit_mmap+0xde/0x3a0
mmput+0xa3/0x250
do_exit+0x564/0x1470
do_group_exit+0x3b/0x100
__do_sys_exit_group+0x13/0x20
__x64_sys_exit_group+0x16/0x20
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Modules linked in:
---[ end trace e99579b570fe0649 ]---
RIP: 0010:release_pages+0x53f/0x840 |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems
where the Dell WMI interface is supported. While exit_dell_smbios_wmi()
unregisters it unconditionally, this leads to the following oops:
[ 175.722921] ------------[ cut here ]------------
[ 175.722925] Unexpected driver unregister!
[ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40
...
[ 175.723089] Call Trace:
[ 175.723094] cleanup_module+0x5/0xedd [dell_smbios]
...
[ 175.723148] ---[ end trace 064c34e1ad49509d ]---
Make the unregister happen on the same condition the register happens
to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix removed dentries still existing after log is synced
When we move one inode from one directory to another and both the inode
and its previous parent directory were logged before, we are not supposed
to have the dentry for the old parent if we have a power failure after the
log is synced. Only the new dentry is supposed to exist.
Generally this works correctly, however there is a scenario where this is
not currently working, because the old parent of the file/directory that
was moved is not authoritative for a range that includes the dir index and
dir item keys of the old dentry. This case is better explained with the
following example and reproducer:
# The test requires a very specific layout of keys and items in the
# fs/subvolume btree to trigger the bug. So we want to make sure that
# on whatever platform we are, we have the same leaf/node size.
#
# Currently in btrfs the node/leaf size can not be smaller than the page
# size (but it can be greater than the page size). So use the largest
# supported node/leaf size (64K).
$ mkfs.btrfs -f -n 65536 /dev/sdc
$ mount /dev/sdc /mnt
# "testdir" is inode 257.
$ mkdir /mnt/testdir
$ chmod 755 /mnt/testdir
# Create several empty files to have the directory "testdir" with its
# items spread over several leaves (7 in this case).
$ for ((i = 1; i <= 1200; i++)); do
echo -n > /mnt/testdir/file$i
done
# Create our test directory "dira", inode number 1458, which gets all
# its items in leaf 7.
#
# The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to
# the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY
# item that points to that entry is in leaf 3.
#
# For this particular filesystem node size (64K), file count and file
# names, we endup with the directory entry items from inode 257 in
# leaves 2 and 3, as previously mentioned - what matters for triggering
# the bug exercised by this test case is that those items are not placed
# in leaf 1, they must be placed in a leaf different from the one
# containing the inode item for inode 257.
#
# The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for
# the parent inode (257) are the following:
#
# item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34
# location key (1458 INODE_ITEM 0) type DIR
# transid 6 data_len 0 name_len 4
# name: dira
#
# and:
#
# item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34
# location key (1458 INODE_ITEM 0) type DIR
# transid 6 data_len 0 name_len 4
# name: dira
$ mkdir /mnt/testdir/dira
# Make sure everything done so far is durably persisted.
$ sync
# Now do a change to inode 257 ("testdir") that does not result in
# COWing leaves 2 and 3 - the leaves that contain the directory items
# pointing to inode 1458 (directory "dira").
#
# Changing permissions, the owner/group, updating or adding a xattr,
# etc, will not change (COW) leaves 2 and 3. So for the sake of
# simplicity change the permissions of inode 257, which results in
# updating its inode item and therefore change (COW) only leaf 1.
$ chmod 700 /mnt/testdir
# Now fsync directory inode 257.
#
# Since only the first leaf was changed/COWed, we log the inode item of
# inode 257 and only the dentries found in the first leaf, all have a
# key type of BTRFS_DIR_ITEM_KEY, and no keys of type
# BTRFS_DIR_INDEX_KEY, because they sort after the former type and none
# exist in the first leaf.
#
# We also log 3 items that represent ranges for dir items and dir
# indexes for which the log is authoritative:
#
# 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is
# authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset
# in the range [0, 2285968570] (the offset here is th
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
async_xor: increase src_offs when dropping destination page
Now we support sharing one page if PAGE_SIZE is not equal stripe size. To
support this, it needs to support calculating xor value with different
offsets for each r5dev. One offset array is used to record those offsets.
In RMW mode, parity page is used as a source page. It sets
ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5.
So it needs to add src_list and src_offs at the same time. Now it only
needs src_list. So the xor value which is calculated is wrong. It can
cause data corruption problem.
I can reproduce this problem 100% on a POWER8 machine. The steps are:
mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G
mkfs.xfs /dev/md0
mount /dev/md0 /mnt/test
mount: /mnt/test: mount(2) system call failed: Structure needs cleaning. |
| 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:
udp: skip L4 aggregation for UDP tunnel packets
If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.
That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.
Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)->gro_receive.
The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.
Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.
v1 -> v2:
- hopefully clarify the commit message |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Remove WO permissions on second-level paging entries
When the first level page table is used for IOVA translation, it only
supports Read-Only and Read-Write permissions. The Write-Only permission
is not supported as the PRESENT bit (implying Read permission) should
always set. When using second level, we still give separate permissions
that allows WriteOnly which seems inconsistent and awkward. We want to
have consistent behavior. After moving to 1st level, we don't want things
to work sometimes, and break if we use 2nd level for the same mappings.
Hence remove this configuration. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s: Fix pte update for kernel memory on radix
When adding a PTE a ptesync is needed to order the update of the PTE
with subsequent accesses otherwise a spurious fault may be raised.
radix__set_pte_at() does not do this for performance gains. For
non-kernel memory this is not an issue as any faults of this kind are
corrected by the page fault handler. For kernel memory these faults
are not handled. The current solution is that there is a ptesync in
flush_cache_vmap() which should be called when mapping from the
vmalloc region.
However, map_kernel_page() does not call flush_cache_vmap(). This is
troublesome in particular for code patching with Strict RWX on radix.
In do_patch_instruction() the page frame that contains the instruction
to be patched is mapped and then immediately patched. With no ordering
or synchronization between setting up the PTE and writing to the page
it is possible for faults.
As the code patching is done using __put_user_asm_goto() the resulting
fault is obscured - but using a normal store instead it can be seen:
BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c
Faulting instruction address: 0xc00000000008bd74
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: nop_module(PO+) [last unloaded: nop_module]
CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43
NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810
REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000
CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1
This results in the kind of issue reported here:
https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/
Chris Riedl suggested a reliable way to reproduce the issue:
$ mount -t debugfs none /sys/kernel/debug
$ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) &
Turning ftrace on and off does a large amount of code patching which
in usually less then 5min will crash giving a trace like:
ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000)
------------[ ftrace bug ]------------
ftrace failed to modify
[<c000000000bf8e5c>] napi_busy_loop+0xc/0x390
actual: 11:3b:47:4b
Setting ftrace call site to call ftrace function
ftrace record flags: 80000001
(1)
expected tramp: c00000000006c96c
------------[ cut here ]------------
WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8
Modules linked in: nop_module(PO-) [last unloaded: nop_module]
CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1
NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0
REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a)
MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000
CFAR: c0000000001a9c98 IRQMASK: 0
GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022
GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8
GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118
GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000
GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008
GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8
GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020
GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0
NIP ftrace_bug+0x28c/0x2e8
LR ftrace_bug+0x288/0x2e8
Call T
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: connac: fix kernel warning adding monitor interface
Fix the following kernel warning adding a monitor interface in
mt76_connac_mcu_uni_add_dev routine.
[ 507.984882] ------------[ cut here ]------------
[ 507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0
[ 508.065461] Hardware name: MT7622_MT7531 RFB (DT)
[ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[ 508.087367] sp : ffffffc013a33930
[ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0
[ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008
[ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610
[ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8
[ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8
[ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000
[ 508.122482] x17: 00000000ffffffff x16: 0000000000000000
[ 508.127785] x15: 0000000000000080 x14: ffffff801d704000
[ 508.133087] x13: 0000000000000040 x12: 0000000000000002
[ 508.138389] x11: 000000000000000c x10: 0000000000000000
[ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001
[ 508.148992] x7 : 0000000000000000 x6 : 0000000000000000
[ 508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006
[ 508.159596] x3 : 0000000000000001 x2 : 0000000000000000
[ 508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0
[ 508.170200] Call trace:
[ 508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[ 508.184394] drv_add_interface+0x34/0x88 [mac80211]
[ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]
[ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211]
[ 508.200328] ieee80211_do_open+0x900/0x918 [mac80211]
[ 508.205372] __dev_open+0xcc/0x150
[ 508.208763] __dev_change_flags+0x134/0x198
[ 508.212937] dev_change_flags+0x20/0x60
[ 508.216764] devinet_ioctl+0x3e8/0x748
[ 508.220503] inet_ioctl+0x1e4/0x350
[ 508.223983] sock_do_ioctl+0x48/0x2a0
[ 508.227635] sock_ioctl+0x310/0x4f8
[ 508.231116] do_vfs_ioctl+0xa4/0xac0
[ 508.234681] ksys_ioctl+0x44/0x90
[ 508.237985] __arm64_sys_ioctl+0x1c/0x48
[ 508.241901] el0_svc_common.constprop.1+0x7c/0x100
[ 508.246681] el0_svc_handler+0x18/0x20
[ 508.250421] el0_svc+0x8/0x1c8
[ 508.253465] ---[ end trace c7b90fee13d72c39 ]---
[ 508.261278] ------------[ cut here ]------------ |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix txrate reporting
Properly check rate_info to fix unexpected reporting.
[ 1215.161863] Call trace:
[ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]
[ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211]
[ 1215.175624] ieee80211_tx_status_ext+0x508/0x838 [mac80211]
[ 1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]
[ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]
[ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]
[ 1215.196582] mt76_dma_cleanup+0x7b0/0x11d0 [mt76]
[ 1215.201276] __napi_poll+0x38/0xf8
[ 1215.204668] napi_workfn+0x40/0x80
[ 1215.208062] process_one_work+0x1fc/0x390
[ 1215.212062] worker_thread+0x48/0x4d0
[ 1215.215715] kthread+0x120/0x128
[ 1215.218935] ret_from_fork+0x10/0x1c |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix kernel crash when the firmware fails to download
Fix kernel crash when the firmware is missing or fails to download.
[ 9.444758] kernel BUG at drivers/pci/msi.c:375!
[ 9.449363] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 9.501033] pstate: a0400009 (NzCv daif +PAN -UAO)
[ 9.505814] pc : free_msi_irqs+0x180/0x184
[ 9.509897] lr : free_msi_irqs+0x40/0x184
[ 9.513893] sp : ffffffc015193870
[ 9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2
[ 9.522492] x27: 0000000000000acd x26: 000000000000009a
[ 9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8
[ 9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200
[ 9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480
[ 9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000
[ 9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34
[ 9.554277] x15: 0000000000000000 x14: 0000000000080800
[ 9.559575] x13: ffffff8cd65a2980 x12: 0000000000000000
[ 9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0
[ 9.570171] x9 : 0000000000000040 x8 : ffffff8ccef1b780
[ 9.575469] x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000
[ 9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000
[ 9.586063] x3 : 0000000000000000 x2 : 0000000000000000
[ 9.591362] x1 : 0000000000000125 x0 : ffffff8ccefe0000
[ 9.596660] Call trace:
[ 9.599095] free_msi_irqs+0x180/0x184
[ 9.602831] pci_disable_msi+0x100/0x130
[ 9.606740] pci_free_irq_vectors+0x24/0x30
[ 9.610915] mt7921_pci_probe+0xbc/0x250 [mt7921e]
[ 9.615693] pci_device_probe+0xd4/0x14c
[ 9.619604] really_probe+0x134/0x2ec
[ 9.623252] driver_probe_device+0x64/0xfc
[ 9.627335] device_driver_attach+0x4c/0x6c
[ 9.631506] __driver_attach+0xac/0xc0
[ 9.635243] bus_for_each_dev+0x8c/0xd4
[ 9.639066] driver_attach+0x2c/0x38
[ 9.642628] bus_add_driver+0xfc/0x1d0
[ 9.646365] driver_register+0x64/0xf8
[ 9.650101] __pci_register_driver+0x6c/0x7c
[ 9.654360] init_module+0x28/0xfdc [mt7921e]
[ 9.658704] do_one_initcall+0x13c/0x2d0
[ 9.662615] do_init_module+0x58/0x1e8
[ 9.666351] load_module+0xd80/0xeb4
[ 9.669912] __arm64_sys_finit_module+0xa8/0xe0
[ 9.674430] el0_svc_common+0xa4/0x16c
[ 9.678168] el0_svc_compat_handler+0x2c/0x40
[ 9.682511] el0_svc_compat+0x8/0x10
[ 9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000)
[ 9.692155] ---[ end trace 7621f966afbf0a29 ]---
[ 9.697385] Kernel panic - not syncing: Fatal exception
[ 9.702599] SMP: stopping secondary CPUs
[ 9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000
[ 9.712456] PHYS_OFFSET: 0xfffffff440000000
[ 9.716625] CPU features: 0x080026,2a80aa18
[ 9.720795] Memory Limit: none |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Always enable the clk on resume
In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:
[ 1.586104] infra_m4u already disabled
[ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[ 1.598108] Modules linked in:
[ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[ 1.617487] Hardware name: Google Elm (DT)
[ 1.617491] Workqueue: pm pm_runtime_work
[ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)
[ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 1.659297] pc : clk_core_disable+0xb0/0xb8
[ 1.663475] lr : clk_core_disable+0xb0/0xb8
[ 1.667652] sp : ffff800011b9bbe0
[ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[ 1.692189] x21: 000000000000000a x20: ffff0000c0048500
[ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[ 1.702804] x17: 0000000000000000 x16: 0000000000000000
[ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[ 1.718727] x11: 0720072007200720 x10: 0720072007200720
[ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[ 1.750572] Call trace:
[ 1.753010] clk_core_disable+0xb0/0xb8
[ 1.756840] clk_core_disable_lock+0x24/0x40
[ 1.761105] clk_disable+0x20/0x30
[ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8
[ 1.769114] pm_generic_runtime_suspend+0x2c/0x48
[ 1.773815] __rpm_callback+0xe0/0x178
[ 1.777559] rpm_callback+0x24/0x88
[ 1.781041] rpm_suspend+0xdc/0x470
[ 1.784523] rpm_idle+0x12c/0x170
[ 1.787831] pm_runtime_work+0xa8/0xc0
[ 1.791573] process_one_work+0x1e8/0x360
[ 1.795580] worker_thread+0x44/0x478
[ 1.799237] kthread+0x150/0x158
[ 1.802460] ret_from_fork+0x10/0x30
[ 1.806034] ---[ end trace 82402920ef64573b ]---
[ 1.810728] ------------[ cut here ]------------
In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix possible invalid register access
Disable the interrupt and synchronze for the pending irq handlers to ensure
the irq tasklet is not being scheduled after the suspend to avoid the
possible invalid register access acts when the host pcie controller is
suspended.
[17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs
[17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00
[17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs
[17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc
[17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs
...
17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300
[17933.620666] Call trace:
[17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76]
[17933.627234] mt7921_rr+0x38/0x44 [mt7921e]
[17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e]
[17933.636309] tasklet_action_common+0x12c/0x16c
[17933.640754] tasklet_action+0x24/0x2c
[17933.644418] __do_softirq+0x16c/0x344
[17933.648082] irq_exit+0xa8/0xac
[17933.651224] scheduler_ipi+0xd4/0x148
[17933.654890] handle_IPI+0x164/0x2d4
[17933.658379] gic_handle_irq+0x140/0x178
[17933.662216] el1_irq+0xb8/0x180
[17933.665361] cpuidle_enter_state+0xf8/0x204
[17933.669544] cpuidle_enter+0x38/0x4c
[17933.673122] do_idle+0x1a4/0x2a8
[17933.676352] cpu_startup_entry+0x24/0x28
[17933.680276] rest_init+0xd4/0xe0
[17933.683508] arch_call_rest_init+0x10/0x18
[17933.687606] start_kernel+0x340/0x3b4
[17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113)
[17933.697373] ---[ end trace a24b8e26ffbda3c5 ]---
[17933.767846] Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/64: Fix the definition of the fixmap area
At the time being, the fixmap area is defined at the top of
the address space or just below KASAN.
This definition is not valid for PPC64.
For PPC64, use the top of the I/O space.
Because of circular dependencies, it is not possible to include
asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size
AREA at the top of the I/O space for fixmap and ensure during
build that the size is big enough. |
| In the Linux kernel, the following vulnerability has been resolved:
m68k: mvme147,mvme16x: Don't wipe PCC timer config bits
Don't clear the timer 1 configuration bits when clearing the interrupt flag
and counter overflow. As Michael reported, "This results in no timer
interrupts being delivered after the first. Initialization then hangs
in calibrate_delay as the jiffies counter is not updated."
On mvme16x, enable the timer after requesting the irq, consistent with
mvme147. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: memcontrol: slab: fix obtain a reference to a freeing memcg
Patch series "Use obj_cgroup APIs to charge kmem pages", v5.
Since Roman's series "The new cgroup slab memory controller" applied.
All slab objects are charged with the new APIs of obj_cgroup. The new
APIs introduce a struct obj_cgroup to charge slab objects. It prevents
long-living objects from pinning the original memory cgroup in the
memory. But there are still some corner objects (e.g. allocations
larger than order-1 page on SLUB) which are not charged with the new
APIs. Those objects (include the pages which are allocated from buddy
allocator directly) are charged as kmem pages which still hold a
reference to the memory cgroup.
E.g. We know that the kernel stack is charged as kmem pages because the
size of the kernel stack can be greater than 2 pages (e.g. 16KB on
x86_64 or arm64). If we create a thread (suppose the thread stack is
charged to memory cgroup A) and then move it from memory cgroup A to
memory cgroup B. Because the kernel stack of the thread hold a
reference to the memory cgroup A. The thread can pin the memory cgroup
A in the memory even if we remove the cgroup A. If we want to see this
scenario by using the following script. We can see that the system has
added 500 dying cgroups (This is not a real world issue, just a script
to show that the large kmallocs are charged as kmem pages which can pin
the memory cgroup in the memory).
#!/bin/bash
cat /proc/cgroups | grep memory
cd /sys/fs/cgroup/memory
echo 1 > memory.move_charge_at_immigrate
for i in range{1..500}
do
mkdir kmem_test
echo $$ > kmem_test/cgroup.procs
sleep 3600 &
echo $$ > cgroup.procs
echo `cat kmem_test/cgroup.procs` > cgroup.procs
rmdir kmem_test
done
cat /proc/cgroups | grep memory
This patchset aims to make those kmem pages to drop the reference to
memory cgroup by using the APIs of obj_cgroup. Finally, we can see that
the number of the dying cgroups will not increase if we run the above test
script.
This patch (of 7):
The rcu_read_lock/unlock only can guarantee that the memcg will not be
freed, but it cannot guarantee the success of css_get (which is in the
refill_stock when cached memcg changed) to memcg.
rcu_read_lock()
memcg = obj_cgroup_memcg(old)
__memcg_kmem_uncharge(memcg)
refill_stock(memcg)
if (stock->cached != memcg)
// css_get can change the ref counter from 0 back to 1.
css_get(&memcg->css)
rcu_read_unlock()
This fix is very like the commit:
eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")
Fix this by holding a reference to the memcg which is passed to the
__memcg_kmem_uncharge() before calling __memcg_kmem_uncharge(). |
| In the Linux kernel, the following vulnerability has been resolved:
ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook
The commit 1879445dfa7b ("perf/core: Set event's default
::overflow_handler()") set a default event->overflow_handler in
perf_event_alloc(), and replace the check event->overflow_handler with
is_default_overflow_handler(), but one is missing.
Currently, the bp->overflow_handler can not be NULL. As a result,
enable_single_step() is always not invoked.
Comments from Zhen Lei:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid touching checkpointed data in get_victim()
In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR
mode to select victim:
1. LFS is set to find source section during GC, the victim should have
no checkpointed data, since after GC, section could not be set free for
reuse.
Previously, we only check valid chpt blocks in current segment rather
than section, fix it.
2. SSR | AT_SSR are set to find target segment for writes which can be
fully filled by checkpointed and newly written blocks, we should never
select such segment, otherwise it can cause panic or data corruption
during allocation, potential case is described as below:
a) target segment has 'n' (n < 512) ckpt valid blocks
b) GC migrates 'n' valid blocks to other segment (segment is still
in dirty list)
c) GC migrates '512 - n' blocks to target segment (segment has 'n'
cp_vblocks and '512 - n' vblocks)
d) If GC selects target segment via {AT,}SSR allocator, however there
is no free space in targe segment. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"
on the command line hits a warning during kernel entry, due to the way
we manipulate the PMR.
Early in the entry sequence, we call lockdep_hardirqs_off() to inform
lockdep that interrupts have been masked (as the HW sets DAIF wqhen
entering an exception). Architecturally PMR_EL1 is not affected by
exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in
the exception entry sequence, so early in exception entry the PMR can
indicate that interrupts are unmasked even though they are masked by
DAIF.
If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that
interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the
exception entry paths, and hence lockdep_hardirqs_off() will WARN() that
something is amiss.
We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during
exception entry so that kernel code sees a consistent environment. We
must also update local_daif_inherit() to undo this, as currently only
touches DAIF. For other paths, local_daif_restore() will update both
DAIF and the PMR. With this done, we can remove the existing special
cases which set this later in the entry code.
We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with
local_daif_save(), as this will warn if it ever encounters
(GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This
matches the gic_prio_kentry_setup that we have to retain for
ret_to_user.
The original splat from Zenghui's report was:
| DEBUG_LOCKS_WARN_ON(!irqs_disabled())
| WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8
| Modules linked in:
| CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
| pc : lockdep_hardirqs_off+0xd4/0xe8
| lr : lockdep_hardirqs_off+0xd4/0xe8
| sp : ffff80002a39bad0
| pmr_save: 000000e0
| x29: ffff80002a39bad0 x28: ffff0000de214bc0
| x27: ffff0000de1c0400 x26: 000000000049b328
| x25: 0000000000406f30 x24: ffff0000de1c00a0
| x23: 0000000020400005 x22: ffff8000105f747c
| x21: 0000000096000044 x20: 0000000000498ef9
| x19: ffff80002a39bc88 x18: ffffffffffffffff
| x17: 0000000000000000 x16: ffff800011c61eb0
| x15: ffff800011700a88 x14: 0720072007200720
| x13: 0720072007200720 x12: 0720072007200720
| x11: 0720072007200720 x10: 0720072007200720
| x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
| x7 : ffff8000119f0800 x6 : c0000000ffff7fff
| x5 : ffff8000119f07a8 x4 : 0000000000000001
| x3 : 9bcdab23f2432800 x2 : ffff800011730538
| x1 : 9bcdab23f2432800 x0 : 0000000000000000
| Call trace:
| lockdep_hardirqs_off+0xd4/0xe8
| enter_from_kernel_mode.isra.5+0x7c/0xa8
| el1_abort+0x24/0x100
| el1_sync_handler+0x80/0xd0
| el1_sync+0x6c/0x100
| __arch_clear_user+0xc/0x90
| load_elf_binary+0x9fc/0x1450
| bprm_execve+0x404/0x880
| kernel_execve+0x180/0x188
| call_usermodehelper_exec_async+0xdc/0x158
| ret_from_fork+0x10/0x18 |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Always make an attempt to map eVMCS after migration
When enlightened VMCS is in use and nested state is migrated with
vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs
page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr'
and we can't read it from VP assist page because userspace may decide
to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state
(and QEMU, for example, does exactly that). To make sure eVMCS is
mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES
request.
Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES
on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to
nested_vmx_vmexit() to make sure MSR permission bitmap is not switched
when an immediate exit from L2 to L1 happens right after migration (caused
by a pending event, for example). Unfortunately, in the exact same
situation we still need to have eVMCS mapped so
nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.
As a band-aid, restore nested_get_evmcs_page() when clearing
KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far
from being ideal as we can't easily propagate possible failures and even if
we could, this is most likely already too late to do so. The whole
'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration
seems to be fragile as we diverge too much from the 'native' path when
vmptr loading happens on vmx_set_nested_state(). |
