Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace<br /> <br /> A received TKIP key may be up to 32 bytes because it may contain<br /> MIC rx/tx keys too. These are not used by iwl and copying these<br /> over overflows the iwl_keyinfo.key field.<br /> <br /> Add a check to not copy more data to iwl_keyinfo.key then will fit.<br /> <br /> This fixes backtraces like this one:<br /> <br /> memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)<br /> WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017<br /> RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Call Trace:<br /> <br /> iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]<br /> iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]<br /> drv_set_key+0xa4/0x1b0 [mac80211]<br /> ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]<br /> ieee80211_key_replace+0x22d/0x8e0 [mac80211]<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: imx: disable Ageing Timer interrupt request irq<br /> <br /> There maybe pending USR interrupt before requesting irq, however<br /> uart_add_one_port has not executed, so there will be kernel panic:<br /> [ 0.795668] Unable to handle kernel NULL pointer dereference at virtual addre<br /> ss 0000000000000080<br /> [ 0.802701] Mem abort info:<br /> [ 0.805367] ESR = 0x0000000096000004<br /> [ 0.808950] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.814033] SET = 0, FnV = 0<br /> [ 0.816950] EA = 0, S1PTW = 0<br /> [ 0.819950] FSC = 0x04: level 0 translation fault<br /> [ 0.824617] Data abort info:<br /> [ 0.827367] ISV = 0, ISS = 0x00000004<br /> [ 0.831033] CM = 0, WnR = 0<br /> [ 0.833866] [0000000000000080] user address but active_mm is swapper<br /> [ 0.839951] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 0.845953] Modules linked in:<br /> [ 0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1<br /> [ 0.855617] Hardware name: Freescale i.MX8MP EVK (DT)<br /> [ 0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0<br /> [ 0.872283] lr : imx_uart_int+0xf8/0x1ec<br /> <br /> The issue only happends in the inmate linux when Jailhouse hypervisor<br /> enabled. The test procedure is:<br /> while true; do<br /> jailhouse enable imx8mp.cell<br /> jailhouse cell linux xxxx<br /> sleep 10<br /> jailhouse cell destroy 1<br /> jailhouse disable<br /> sleep 5<br /> done<br /> <br /> And during the upper test, press keys to the 2nd linux console.<br /> When `jailhouse cell destroy 1`, the 2nd linux has no chance to put<br /> the uart to a quiese state, so USR1/2 may has pending interrupts. Then<br /> when `jailhosue cell linux xx` to start 2nd linux again, the issue<br /> trigger.<br /> <br /> In order to disable irqs before requesting them, both UCR1 and UCR2 irqs<br /> should be disabled, so here fix that, disable the Ageing Timer interrupt<br /> in UCR2 as UCR1 does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fortify the spinlock against deadlock by interrupt<br /> <br /> In the function ieee80211_tx_dequeue() there is a particular locking<br /> sequence:<br /> <br /> begin:<br /> spin_lock(&amp;local-&gt;queue_stop_reason_lock);<br /> q_stopped = local-&gt;queue_stop_reasons[q];<br /> spin_unlock(&amp;local-&gt;queue_stop_reason_lock);<br /> <br /> However small the chance (increased by ftracetest), an asynchronous<br /> interrupt can occur in between of spin_lock() and spin_unlock(),<br /> and the interrupt routine will attempt to lock the same<br /> &amp;local-&gt;queue_stop_reason_lock again.<br /> <br /> This will cause a costly reset of the CPU and the wifi device or an<br /> altogether hang in the single CPU and single core scenario.<br /> <br /> The only remaining spin_lock(&amp;local-&gt;queue_stop_reason_lock) that<br /> did not disable interrupts was patched, which should prevent any<br /> deadlocks on the same CPU/core and the same wifi device.<br /> <br /> This is the probable trace of the deadlock:<br /> <br /> kernel: ================================<br /> kernel: WARNING: inconsistent lock state<br /> kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W<br /> kernel: --------------------------------<br /> kernel: inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> kernel: ffff9d6190779478 (&amp;local-&gt;queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40<br /> kernel: {IN-SOFTIRQ-W} state was registered at:<br /> kernel: lock_acquire+0xc7/0x2d0<br /> kernel: _raw_spin_lock+0x36/0x50<br /> kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]<br /> kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]<br /> kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]<br /> kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]<br /> kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]<br /> kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]<br /> kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]<br /> kernel: dev_hard_start_xmit+0xb5/0x260<br /> kernel: __dev_queue_xmit+0xdbe/0x1200<br /> kernel: neigh_resolve_output+0x166/0x260<br /> kernel: ip_finish_output2+0x216/0xb80<br /> kernel: __ip_finish_output+0x2a4/0x4d0<br /> kernel: ip_finish_output+0x2d/0xd0<br /> kernel: ip_output+0x82/0x2b0<br /> kernel: ip_local_out+0xec/0x110<br /> kernel: igmpv3_sendpack+0x5c/0x90<br /> kernel: igmp_ifc_timer_expire+0x26e/0x4e0<br /> kernel: call_timer_fn+0xa5/0x230<br /> kernel: run_timer_softirq+0x27f/0x550<br /> kernel: __do_softirq+0xb4/0x3a4<br /> kernel: irq_exit_rcu+0x9b/0xc0<br /> kernel: sysvec_apic_timer_interrupt+0x80/0xa0<br /> kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30<br /> kernel: _raw_spin_unlock_irqrestore+0x3f/0x70<br /> kernel: free_to_partial_list+0x3d6/0x590<br /> kernel: __slab_free+0x1b7/0x310<br /> kernel: kmem_cache_free+0x52d/0x550<br /> kernel: putname+0x5d/0x70<br /> kernel: do_sys_openat2+0x1d7/0x310<br /> kernel: do_sys_open+0x51/0x80<br /> kernel: __x64_sys_openat+0x24/0x30<br /> kernel: do_syscall_64+0x5c/0x90<br /> kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> kernel: irq event stamp: 5120729<br /> kernel: hardirqs last enabled at (5120729): [] trace_graph_return+0xd6/0x120<br /> kernel: hardirqs last disabled at (5120728): [] trace_graph_return+0xf0/0x120<br /> kernel: softirqs last enabled at (5069900): [] return_to_handler+0x0/0x40<br /> kernel: softirqs last disabled at (5067555): [] return_to_handler+0x0/0x40<br /> kernel:<br /> other info that might help us debug this:<br /> kernel: Possible unsafe locking scenario:<br /> kernel: CPU0<br /> kernel: ----<br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel: <br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel:<br /> *** DEADLOCK ***<br /> kernel: 8 locks held by kworker/5:0/25656:<br /> kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530<br /> kernel: #1: ffffb1ef4637fe68 ((work_completion)(&amp;local-&gt;restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530<br /> kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40<br /> kernel: #3: ffff9d619<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Fix NULL dereference in error handling<br /> <br /> Smatch reported:<br /> <br /> drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()<br /> warn: missing unwind goto?<br /> <br /> At this point in the function, nothing has been allocated so we can return<br /> directly. In particular the "qedf-&gt;global_queues" have not been allocated<br /> so calling qedf_free_global_queues() will lead to a NULL dereference when<br /> we check if (!gl[i]) and "gl" is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init<br /> <br /> blk-iocost sometimes causes the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000e0<br /> ...<br /> RIP: 0010:_raw_spin_lock+0x17/0x30<br /> Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00<br /> RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001<br /> RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0<br /> RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003<br /> R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000<br /> R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600<br /> FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0<br /> Call Trace:<br /> <br /> ioc_weight_write+0x13d/0x410<br /> cgroup_file_write+0x7a/0x130<br /> kernfs_fop_write_iter+0xf5/0x170<br /> vfs_write+0x298/0x370<br /> ksys_write+0x5f/0xb0<br /> __x64_sys_write+0x1b/0x20<br /> do_syscall_64+0x3d/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This happens because iocg-&gt;ioc is NULL. The field is initialized by<br /> ioc_pd_init() and never cleared. The NULL deref is caused by<br /> blkcg_activate_policy() installing blkg_policy_data before initializing it.<br /> <br /> blkcg_activate_policy() was doing the following:<br /> <br /> 1. Allocate pd&amp;#39;s for all existing blkg&amp;#39;s and install them in blkg-&gt;pd[].<br /> 2. Initialize all pd&amp;#39;s.<br /> 3. Online all pd&amp;#39;s.<br /> <br /> blkcg_activate_policy() only grabs the queue_lock and may release and<br /> re-acquire the lock as allocation may need to sleep. ioc_weight_write()<br /> grabs blkcg-&gt;lock and iterates all its blkg&amp;#39;s. The two can race and if<br /> ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a<br /> pd which is not initialized yet, leading to crash.<br /> <br /> The crash can be reproduced with the following script:<br /> <br /> #!/bin/bash<br /> <br /> echo +io &gt; /sys/fs/cgroup/cgroup.subtree_control<br /> systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct<br /> echo 100 &gt; /sys/fs/cgroup/system.slice/io.weight<br /> bash -c "echo &amp;#39;8:0 enable=1&amp;#39; &gt; /sys/fs/cgroup/io.cost.qos" &amp;<br /> sleep .2<br /> echo 100 &gt; /sys/fs/cgroup/system.slice/io.weight<br /> <br /> with the following patch applied:<br /> <br /> &gt; diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c<br /> &gt; index fc49be622e05..38d671d5e10c 100644<br /> &gt; --- a/block/blk-cgroup.c<br /> &gt; +++ b/block/blk-cgroup.c<br /> &gt; @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)<br /> &gt; pd-&gt;online = false;<br /> &gt; }<br /> &gt;<br /> &gt; + if (system_state == SYSTEM_RUNNING) {<br /> &gt; + spin_unlock_irq(&amp;q-&gt;queue_lock);<br /> &gt; + ssleep(1);<br /> &gt; + spin_lock_irq(&amp;q-&gt;queue_lock);<br /> &gt; + }<br /> &gt; +<br /> &gt; /* all allocated, init in the same order */<br /> &gt; if (pol-&gt;pd_init_fn)<br /> &gt; list_for_each_entry_reverse(blkg, &amp;q-&gt;blkg_list, q_node)<br /> <br /> I don&amp;#39;t see a reason why all pd&amp;#39;s should be allocated, initialized and<br /> onlined together. The only ordering requirement is that parent blkgs to be<br /> initialized and onlined before children, which is guaranteed from the<br /> walking order. Let&amp;#39;s fix the bug by allocating, initializing and onlining pd<br /> for each blkg and holding blkcg-&gt;lock over initialization and onlining. This<br /> ensures that an installed blkg is always fully initialized and onlined<br /> removing the the race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix a possible null-pointer dereference in ni_clear()<br /> <br /> In a previous commit c1006bd13146, ni-&gt;mi.mrec in ni_write_inode()<br /> could be NULL, and thus a NULL check is added for this variable.<br /> <br /> However, in the same call stack, ni-&gt;mi.mrec can be also dereferenced<br /> in ni_clear():<br /> <br /> ntfs_evict_inode(inode)<br /> ni_write_inode(inode, ...)<br /> ni = ntfs_i(inode);<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; Add a NULL check by previous commit<br /> ni_clear(ntfs_i(inode))<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; No check<br /> <br /> Thus, a possible null-pointer dereference may exist in ni_clear().<br /> To fix it, a NULL check is added in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Fix leak of dev tracker<br /> <br /> At the stage of direction checks, the netdev reference tracker is<br /> already initialized, but released with wrong *_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Add a check for valid &amp;#39;mad_agent&amp;#39; pointer<br /> <br /> When unregistering MAD agent, srpt module has a non-null check<br /> for &amp;#39;mad_agent&amp;#39; pointer before invoking ib_unregister_mad_agent().<br /> This check can pass if &amp;#39;mad_agent&amp;#39; variable holds an error value.<br /> The &amp;#39;mad_agent&amp;#39; can have an error value for a short window when<br /> srpt_add_one() and srpt_remove_one() is executed simultaneously.<br /> <br /> In srpt module, added a valid pointer check for &amp;#39;sport-&gt;mad_agent&amp;#39;<br /> before unregistering MAD agent.<br /> <br /> This issue can hit when RoCE driver unregisters ib_device<br /> <br /> Stack Trace:<br /> ------------<br /> BUG: kernel NULL pointer dereference, address: 000000000000004d<br /> PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P<br /> Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020<br /> Workqueue: bnxt_re bnxt_re_task [bnxt_re]<br /> RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40<br /> Call Trace:<br /> ib_unregister_mad_agent+0x46/0x2f0 [ib_core]<br /> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready<br /> ? __schedule+0x20b/0x560<br /> srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]<br /> srpt_remove_one+0x20/0x150 [ib_srpt]<br /> remove_client_context+0x88/0xd0 [ib_core]<br /> bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex<br /> disable_device+0x8a/0x160 [ib_core]<br /> bond0: active interface up!<br /> ? kernfs_name_hash+0x12/0x80<br /> (NULL device *): Bonding Info Received: rdev: 000000006c0b8247<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> (NULL device *): Master: mode: 4 num_slaves:2<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> (NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0<br /> bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]<br /> bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Fix memory leak in ath11k_peer_rx_frag_setup<br /> <br /> crypto_alloc_shash() allocates resources, which should be released by<br /> crypto_free_shash(). When ath11k_peer_find() fails, there has memory<br /> leak. Add missing crypto_free_shash() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net<br /> <br /> Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd<br /> startup") moved the initialization of the reply cache into nfsd startup,<br /> but didn&amp;#39;t account for the stats counters, which can be accessed before<br /> nfsd is ever started. The result can be a NULL pointer dereference when<br /> someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still<br /> shut down.<br /> <br /> This is a regression and a user-triggerable oops in the right situation:<br /> <br /> - non-x86_64 arch<br /> - /proc/fs/nfsd is mounted in the namespace<br /> - nfsd is not started in the namespace<br /> - unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"<br /> <br /> Although this is easy to trigger on some arches (like aarch64), on<br /> x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the<br /> fixed_percpu_data. That struct looks just enough like a newly<br /> initialized percpu var to allow nfsd_reply_cache_stats_show to access<br /> it without Oopsing.<br /> <br /> Move the initialization of the per-net+per-cpu reply-cache counters<br /> back into nfsd_init_net, while leaving the rest of the reply cache<br /> allocations to be done at nfsd startup time.<br /> <br /> Kudos to Eirik who did most of the legwork to track this down.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: udlfb: Fix endpoint check<br /> <br /> The syzbot fuzzer detected a problem in the udlfb driver, caused by an<br /> endpoint not having the expected type:<br /> <br /> usb 1-1: Read EDID byte 0 failed: -71<br /> usb 1-1: Unable to get valid EDID from device/display<br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880<br /> drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted<br /> 6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 04/28/2023<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> ...<br /> Call Trace:<br /> <br /> dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980<br /> dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315<br /> dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111<br /> dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743<br /> <br /> The current approach for this issue failed to catch the problem<br /> because it only checks for the existence of a bulk-OUT endpoint; it<br /> doesn&amp;#39;t check whether this endpoint is the one that the driver will<br /> actually use.<br /> <br /> We can fix the problem by instead checking that the endpoint used by<br /> the driver does exist and is bulk-OUT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vmem: split pages when debug pagealloc is enabled<br /> <br /> Since commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")<br /> the kernel crashes early during boot when debug pagealloc is enabled:<br /> <br /> mem auto-init: stack:off, heap alloc:off, heap free:off<br /> addressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630<br /> [..]<br /> Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e<br /> 00000000001325fc: eb880002000c srlg %r8,%r8,2<br /> #0000000000132602: b2210051 ipte %r5,%r1,%r0,0<br /> &gt;0000000000132606: b90400d1 lgr %r13,%r1<br /> 000000000013260a: 41605008 la %r6,8(%r5)<br /> 000000000013260e: a7db1000 aghi %r13,4096<br /> 0000000000132612: b221006d ipte %r6,%r13,%r0,0<br /> 0000000000132616: e3d0d0000171 lay %r13,4096(%r13)<br /> <br /> Call Trace:<br /> __kernel_map_pages+0x14e/0x320<br /> __free_pages_ok+0x23a/0x5a8)<br /> free_low_memory_core_early+0x214/0x2c8<br /> memblock_free_all+0x28/0x58<br /> mem_init+0xb6/0x228<br /> mm_core_init+0xb6/0x3b0<br /> start_kernel+0x1d2/0x5a8<br /> startup_continue+0x36/0x40<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops<br /> <br /> This is caused by using large mappings on machines with EDAT1/EDAT2. Add<br /> the code to split the mappings into 4k pages if debug pagealloc is enabled<br /> by CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel<br /> command line option.