Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: hibernate: Fix level3 translation fault in swsusp_save()<br /> <br /> On arm64 machines, swsusp_save() faults if it attempts to access<br /> MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI<br /> when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n:<br /> <br /> Unable to handle kernel paging request at virtual address ffffff8000000000<br /> Mem abort info:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: level 3 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000<br /> [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000<br /> Internal error: Oops: 0000000096000007 [#1] SMP<br /> Internal error: Oops: 0000000096000007 [#1] SMP<br /> Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm<br /> CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76<br /> Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0<br /> Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021<br /> pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : swsusp_save+0x280/0x538<br /> lr : swsusp_save+0x280/0x538<br /> sp : ffffffa034a3fa40<br /> x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000<br /> x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000<br /> x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2<br /> x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000<br /> x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666<br /> x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea<br /> x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0<br /> x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001<br /> x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e<br /> Call trace:<br /> swsusp_save+0x280/0x538<br /> swsusp_arch_suspend+0x148/0x190<br /> hibernation_snapshot+0x240/0x39c<br /> hibernate+0xc4/0x378<br /> state_store+0xf0/0x10c<br /> kobj_attr_store+0x14/0x24<br /> <br /> The reason is swsusp_save() -&gt; copy_data_pages() -&gt; page_is_saveable()<br /> -&gt; kernel_page_present() assuming that a page is always present when<br /> can_set_direct_map() is false (all of rodata_full,<br /> debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),<br /> irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions<br /> should not be saved during hibernation.<br /> <br /> This problem was introduced by changes to the pfn_valid() logic in<br /> commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify<br /> pfn_valid()").<br /> <br /> Similar to other architectures, drop the !can_set_direct_map() check in<br /> kernel_page_present() so that page_is_savable() skips such pages.<br /> <br /> [catalin.marinas@arm.com: rework commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: x86: Don&amp;#39;t overflow lpage_info when checking attributes<br /> <br /> Fix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger<br /> KASAN splat, as seen in the private_mem_conversions_test selftest.<br /> <br /> When memory attributes are set on a GFN range, that range will have<br /> specific properties applied to the TDP. A huge page cannot be used when<br /> the attributes are inconsistent, so they are disabled for those the<br /> specific huge pages. For internal KVM reasons, huge pages are also not<br /> allowed to span adjacent memslots regardless of whether the backing memory<br /> could be mapped as huge.<br /> <br /> What GFNs support which huge page sizes is tracked by an array of arrays<br /> &amp;#39;lpage_info&amp;#39; on the memslot, of ‘kvm_lpage_info’ structs. Each index of<br /> lpage_info contains a vmalloc allocated array of these for a specific<br /> supported page size. The kvm_lpage_info denotes whether a specific huge<br /> page (GFN and page size) on the memslot is supported. These arrays include<br /> indices for unaligned head and tail huge pages.<br /> <br /> Preventing huge pages from spanning adjacent memslot is covered by<br /> incrementing the count in head and tail kvm_lpage_info when the memslot is<br /> allocated, but disallowing huge pages for memory that has mixed attributes<br /> has to be done in a more complicated way. During the<br /> KVM_SET_MEMORY_ATTRIBUTES ioctl KVM updates lpage_info for each memslot in<br /> the range that has mismatched attributes. KVM does this a memslot at a<br /> time, and marks a special bit, KVM_LPAGE_MIXED_FLAG, in the kvm_lpage_info<br /> for any huge page. This bit is essentially a permanently elevated count.<br /> So huge pages will not be mapped for the GFN at that page size if the<br /> count is elevated in either case: a huge head or tail page unaligned to<br /> the memslot or if KVM_LPAGE_MIXED_FLAG is set because it has mixed<br /> attributes.<br /> <br /> To determine whether a huge page has consistent attributes, the<br /> KVM_SET_MEMORY_ATTRIBUTES operation checks an xarray to make sure it<br /> consistently has the incoming attribute. Since level - 1 huge pages are<br /> aligned to level huge pages, it employs an optimization. As long as the<br /> level - 1 huge pages are checked first, it can just check these and assume<br /> that if each level - 1 huge page contained within the level sized huge<br /> page is not mixed, then the level size huge page is not mixed. This<br /> optimization happens in the helper hugepage_has_attrs().<br /> <br /> Unfortunately, although the kvm_lpage_info array representing page size<br /> &amp;#39;level&amp;#39; will contain an entry for an unaligned tail page of size level,<br /> the array for level - 1 will not contain an entry for each GFN at page<br /> size level. The level - 1 array will only contain an index for any<br /> unaligned region covered by level - 1 huge page size, which can be a<br /> smaller region. So this causes the optimization to overflow the level - 1<br /> kvm_lpage_info and perform a vmalloc out of bounds read.<br /> <br /> In some cases of head and tail pages where an overflow could happen,<br /> callers skip the operation completely as KVM_LPAGE_MIXED_FLAG is not<br /> required to prevent huge pages as discussed earlier. But for memslots that<br /> are smaller than the 1GB page size, it does call hugepage_has_attrs(). In<br /> this case the huge page is both the head and tail page. The issue can be<br /> observed simply by compiling the kernel with CONFIG_KASAN_VMALLOC and<br /> running the selftest “private_mem_conversions_test”, which produces the<br /> output like the following:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in hugepage_has_attrs+0x7e/0x110<br /> Read of size 4 at addr ffffc900000a3008 by task private_mem_con/169<br /> Call Trace:<br /> dump_stack_lvl<br /> print_report<br /> ? __virt_addr_valid<br /> ? hugepage_has_attrs<br /> ? hugepage_has_attrs<br /> kasan_report<br /> ? hugepage_has_attrs<br /> hugepage_has_attrs<br /> kvm_arch_post_set_memory_attributes<br /> kvm_vm_ioctl<br /> <br /> It is a little ambiguous whether the unaligned head page (in the bug case<br /> also the tail page) should be expected to have KVM_LPAGE_MIXED_FLAG set.<br /> It is not functionally required, as the unal<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status<br /> <br /> Check kvm_mmu_page_ad_need_write_protect() when deciding whether to<br /> write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU<br /> accounts for any role-specific reasons for disabling D-bit dirty logging.<br /> <br /> Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is<br /> being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled.<br /> KVM always disables PML when running L2, even when L1 and L2 GPAs are in<br /> the some domain, so failing to write-protect TDP MMU SPTEs will cause<br /> writes made by L2 to not be reflected in the dirty log.<br /> <br /> [sean: massage shortlog and changelog, tweak ternary op formatting]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/pmu: Disable support for adaptive PEBS<br /> <br /> Drop support for virtualizing adaptive PEBS, as KVM&amp;#39;s implementation is<br /> architecturally broken without an obvious/easy path forward, and because<br /> exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak<br /> host kernel addresses to the guest.<br /> <br /> Bug #1 is that KVM doesn&amp;#39;t account for the upper 32 bits of<br /> IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g<br /> fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters()<br /> stores local variables as u8s and truncates the upper bits too, etc.<br /> <br /> Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value<br /> for PEBS events, perf will _always_ generate an adaptive record, even if<br /> the guest requested a basic record. Note, KVM will also enable adaptive<br /> PEBS in individual *counter*, even if adaptive PEBS isn&amp;#39;t exposed to the<br /> guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero,<br /> i.e. the guest will only ever see Basic records.<br /> <br /> Bug #3 is in perf. intel_pmu_disable_fixed() doesn&amp;#39;t clear the upper<br /> bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and<br /> intel_pmu_enable_fixed() effectively doesn&amp;#39;t clear ICL_FIXED_0_ADAPTIVE<br /> either. I.e. perf _always_ enables ADAPTIVE counters, regardless of what<br /> KVM requests.<br /> <br /> Bug #4 is that adaptive PEBS *might* effectively bypass event filters set<br /> by the host, as "Updated Memory Access Info Group" records information<br /> that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER.<br /> <br /> Bug #5 is that KVM doesn&amp;#39;t ensure LBR MSRs hold guest values (or at least<br /> zeros) when entering a vCPU with adaptive PEBS, which allows the guest<br /> to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries"<br /> records.<br /> <br /> Disable adaptive PEBS support as an immediate fix due to the severity of<br /> the LBR leak in particular, and because fixing all of the bugs will be<br /> non-trivial, e.g. not suitable for backporting to stable kernels.<br /> <br /> Note! This will break live migration, but trying to make KVM play nice<br /> with live migration would be quite complicated, wouldn&amp;#39;t be guaranteed to<br /> work (i.e. KVM might still kill/confuse the guest), and it&amp;#39;s not clear<br /> that there are any publicly available VMMs that support adaptive PEBS,<br /> let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn&amp;#39;t<br /> support PEBS in any capacity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: max310x: fix NULL pointer dereference in I2C instantiation<br /> <br /> When trying to instantiate a max14830 device from userspace:<br /> <br /> echo max14830 0x60 &gt; /sys/bus/i2c/devices/i2c-2/new_device<br /> <br /> we get the following error:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address...<br /> ...<br /> Call trace:<br /> max310x_i2c_probe+0x48/0x170 [max310x]<br /> i2c_device_probe+0x150/0x2a0<br /> ...<br /> <br /> Add check for validity of devtype to prevent the error, and abort probe<br /> with a meaningful error message.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix OOB in nilfs_set_de_type<br /> <br /> The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is<br /> defined as "S_IFMT &gt;&gt; S_SHIFT", but the nilfs_set_de_type() function,<br /> which uses this array, specifies the index to read from the array in the<br /> same way as "(mode &amp; S_IFMT) &gt;&gt; S_SHIFT".<br /> <br /> static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode<br /> *inode)<br /> {<br /> umode_t mode = inode-&gt;i_mode;<br /> <br /> de-&gt;file_type = nilfs_type_by_mode[(mode &amp; S_IFMT)&gt;&gt;S_SHIFT]; // oob<br /> }<br /> <br /> However, when the index is determined this way, an out-of-bounds (OOB)<br /> error occurs by referring to an index that is 1 larger than the array size<br /> when the condition "mode &amp; S_IFMT == S_IFMT" is satisfied. Therefore, a<br /> patch to resize the nilfs_type_by_mode array should be applied to prevent<br /> OOB errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: check the inode number is not the invalid value of zero<br /> <br /> Syskiller has produced an out of bounds access in fill_meta_index().<br /> <br /> That out of bounds access is ultimately caused because the inode<br /> has an inode number with the invalid value of zero, which was not checked.<br /> <br /> The reason this causes the out of bounds access is due to following<br /> sequence of events:<br /> <br /> 1. Fill_meta_index() is called to allocate (via empty_meta_index())<br /> and fill a metadata index. It however suffers a data read error<br /> and aborts, invalidating the newly returned empty metadata index.<br /> It does this by setting the inode number of the index to zero,<br /> which means unused (zero is not a valid inode number).<br /> <br /> 2. When fill_meta_index() is subsequently called again on another<br /> read operation, locate_meta_index() returns the previous index<br /> because it matches the inode number of 0. Because this index<br /> has been returned it is expected to have been filled, and because<br /> it hasn&amp;#39;t been, an out of bounds access is performed.<br /> <br /> This patch adds a sanity check which checks that the inode number<br /> is not zero when the inode is created and returns -EINVAL if it is.<br /> <br /> [phillip@squashfs.org.uk: whitespace fix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau: fix instmem race condition around ptr stores<br /> <br /> Running a lot of VK CTS in parallel against nouveau, once every<br /> few hours you might see something like this crash.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27<br /> Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021<br /> RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]<br /> Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1<br /> RSP: 0000:ffffac20c5857838 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001<br /> RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180<br /> RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10<br /> R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c<br /> R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c<br /> FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ...<br /> <br /> ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]<br /> ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]<br /> nvkm_vmm_iter+0x351/0xa20 [nouveau]<br /> ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]<br /> ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]<br /> ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]<br /> ? __lock_acquire+0x3ed/0x2170<br /> ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]<br /> nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]<br /> ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]<br /> ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]<br /> nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]<br /> <br /> Adding any sort of useful debug usually makes it go away, so I hand<br /> wrote the function in a line, and debugged the asm.<br /> <br /> Every so often pt-&gt;memory-&gt;ptrs is NULL. This ptrs ptr is set in<br /> the nv50_instobj_acquire called from nvkm_kmap.<br /> <br /> If Thread A and Thread B both get to nv50_instobj_acquire around<br /> the same time, and Thread A hits the refcount_set line, and in<br /> lockstep thread B succeeds at refcount_inc_not_zero, there is a<br /> chance the ptrs value won&amp;#39;t have been stored since refcount_set<br /> is unordered. Force a memory barrier here, I picked smp_mb, since<br /> we want it on all CPUs and it&amp;#39;s write followed by a read.<br /> <br /> v2: use paired smp_rmb/smp_wmb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf<br /> <br /> If -&gt;ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size<br /> validation could be skipped. if request size is smaller than<br /> sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in<br /> smb2_allocate_rsp_buf(). This patch allocate response buffer after<br /> decrypting transform request. smb3_decrypt_req() will validate transform<br /> request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bootconfig: use memblock_free_late to free xbc memory to buddy<br /> <br /> On the time to free xbc memory in xbc_exit(), memblock may has handed<br /> over memory to buddy allocator. So it doesn&amp;#39;t make sense to free memory<br /> back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs<br /> on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86.<br /> Following KASAN logs shows this case.<br /> <br /> This patch fixes the xbc memory free problem by calling memblock_free()<br /> in early xbc init error rewind path and calling memblock_free_late() in<br /> xbc exit path to free memory to buddy allocator.<br /> <br /> [ 9.410890] ==================================================================<br /> [ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260<br /> [ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1<br /> <br /> [ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5<br /> [ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023<br /> [ 9.460789] Call Trace:<br /> [ 9.463518] <br /> [ 9.465859] dump_stack_lvl+0x53/0x70<br /> [ 9.469949] print_report+0xce/0x610<br /> [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0<br /> [ 9.478619] ? memblock_isolate_range+0x12d/0x260<br /> [ 9.483877] kasan_report+0xc6/0x100<br /> [ 9.487870] ? memblock_isolate_range+0x12d/0x260<br /> [ 9.493125] memblock_isolate_range+0x12d/0x260<br /> [ 9.498187] memblock_phys_free+0xb4/0x160<br /> [ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10<br /> [ 9.508021] ? mutex_unlock+0x7e/0xd0<br /> [ 9.512111] ? __pfx_mutex_unlock+0x10/0x10<br /> [ 9.516786] ? kernel_init_freeable+0x2d4/0x430<br /> [ 9.521850] ? __pfx_kernel_init+0x10/0x10<br /> [ 9.526426] xbc_exit+0x17/0x70<br /> [ 9.529935] kernel_init+0x38/0x1e0<br /> [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30<br /> [ 9.538601] ret_from_fork+0x2c/0x50<br /> [ 9.542596] ? __pfx_kernel_init+0x10/0x10<br /> [ 9.547170] ret_from_fork_asm+0x1a/0x30<br /> [ 9.551552] <br /> <br /> [ 9.555649] The buggy address belongs to the physical page:<br /> [ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30<br /> [ 9.570821] flags: 0x200000000000000(node=0|zone=2)<br /> [ 9.576271] page_type: 0xffffffff()<br /> [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000<br /> [ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 9.597476] page dumped because: kasan: bad access detected<br /> <br /> [ 9.605362] Memory state around the buggy address:<br /> [ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 9.626857] &gt;ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 9.634930] ^<br /> [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 9.654675] ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: intel_rapl: Fix a NULL pointer dereference<br /> <br /> A NULL pointer dereference is triggered when probing the MMIO RAPL<br /> driver on platforms with CPU ID not listed in intel_rapl_common CPU<br /> model list.<br /> <br /> This is because the intel_rapl_common module still probes on such<br /> platforms even if &amp;#39;defaults_msr&amp;#39; is not set after commit 1488ac990ac8<br /> ("powercap: intel_rapl: Allow probing without CPUID match"). Thus the<br /> MMIO RAPL rp-&gt;priv-&gt;defaults is NULL when registering to RAPL framework.<br /> <br /> Fix the problem by adding sanity check to ensure rp-&gt;priv-&gt;rapl_defaults<br /> is always valid.