-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot allocate main ToPA buffer! #4
Comments
Candidate fixes: |
Wenzel
pushed a commit
that referenced
this issue
Jan 17, 2023
The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET. Reported-by: Lucas Leong <wmliang.tw@gmail.com> Tested: verified that EINVAL is correctly returned when secretlen > len(secret) Fixes: 4f4853d ("ipv6: sr: implement API to control SR HMAC structure") Signed-off-by: David Lebrun <dlebrun@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wenzel
pushed a commit
that referenced
this issue
Jan 17, 2023
Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c [ 334.976854] invoke_syscall+0x78/0x100 [ 334.980594] el0_svc_common.constprop.0+0x4c/0xf4 [ 334.985287] do_el0_svc+0x38/0x4c [ 334.988591] el0_svc+0x34/0x10c [ 334.991724] el0t_64_sync_handler+0x11c/0x150 [ 334.996072] el0t_64_sync+0x190/0x194 [ 334.999726] Code: b9001062 f9403c02 d53cd044 8b040042 (b8210040) [ 335.005810] ---[ end trace 0000000000000000 ]--- [ 335.010416] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 335.017279] SMP: stopping secondary CPUs [ 335.021374] Kernel Offset: 0x5baca8eb0000 from 0xffff800008000000 [ 335.027456] PHYS_OFFSET: 0x80000000 [ 335.030932] CPU features: 0x0000,0085c029,19805c82 [ 335.035713] Memory Limit: none [ 335.038756] Rebooting in 180 seconds.. The fix is to allocate the memory in bond_open() which is guaranteed to be called before any packets are processed. Fixes: 848ca91 ("net: bonding: Use per-cpu rr_tx_counter") CC: Jussi Maki <joamaki@gmail.com> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wenzel
pushed a commit
that referenced
this issue
Jan 17, 2023
When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero when depth is > 0. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this: [ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 [ 135.281612] ? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 [ 135.285646] read_pages+0x67/0x1d0 [ 135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [ 135.290332] filemap_read+0xbf/0x300 [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This patch simply adds an extra check in __ext4_ext_check(), verifying that eh_entries is not 0 when eh_depth is > 0. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215941 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216283 Cc: Baokun Li <libaokun1@huawei.com> Cc: stable@kernel.org Signed-off-by: Luís Henriques <lhenriques@suse.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20220822094235.2690-1-lhenriques@suse.de Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Getting ToPA buffer full issues on Nyx kernel 6.0 [336740.279414] [KVM-NYX] Error: Cannot allocate main ToPA buffer!
[336740.279421] [KVM-NYX] Info: ToPA setup failed...
[336740.282401] [KVM-NYX] Error: Cannot allocate main ToPA buffer!
[336740.282408] [KVM-NYX] Info: ToPA setup failed...
[336740.284820] [KVM-NYX] Error: Cannot allocate main ToPA buffer!
[336740.284825] [KVM-NYX] Info: ToPA setup failed...
[336740.286784] [KVM-NYX] Error: Cannot allocate main ToPA buffer!
[336740.286789] [KVM-NYX] Info: ToPA setup failed...
[336740.908527] BUG: kernel NULL pointer dereference, address: 0000000000000098
[336740.908535] #PF: supervisor read access in kernel mode
[336740.908538] #PF: error_code(0x0000) - not-present page
[336740.908541] PGD 0 P4D 0
[336740.908546] Oops: 0000 [#4] PREEMPT SMP PTI
[336740.908550] CPU: 0 PID: 272377 Comm: CPU 0/KVM Tainted: G D I 6.0.0-nyx+ #1
[336740.908555] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0073.2020.0909.1625 09/09/2020
[336740.908558] RIP: 0010:topa_full+0x6/0x60 [kvm_intel]
[336740.908581] Code: fc 5b 41 5c 5d c3 cc cc cc cc 65 8b 15 fb 36 34 3f 48 c7 c7 a5 cb ce c0 e8 ab 69 68 fc eb 90 0f 1f 44 00 00 0f 1f 44 00 00 55 <48> 8b 87 98 00 00 00 48 89 e5 a9 80 ff ff ff 75 1d 48 c1 e8 20 48
[336740.908586] RSP: 0018:ffffbc5a88043c70 EFLAGS: 00010046
[336740.908590] RAX: 0000000000000000 RBX: ffff90e10d6d8000 RCX: ffff90e100d849c0
[336740.908594] RDX: ffff90e1f7040500 RSI: ffffffffc0c21f4f RDI: 0000000000000000
[336740.908597] RBP: ffffbc5a88043cc0 R08: ffff90e46ec00000 R09: 00000000000000b8
[336740.908600] R10: 0000000000000007 R11: 00007fe251e5c000 R12: ffff90e161155180
[336740.908603] R13: 0000000000000000 R14: 0000000000000000 R15: ffff90e161155398
[336740.908607] FS: 00007fe24cf32700(0000) GS:ffff90e46ec00000(0000) knlGS:0000000000000000
[336740.908610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[336740.908614] CR2: 0000000000000098 CR3: 000000012c498002 CR4: 00000000003726f0
[336740.908617] Call Trace:
[336740.908620] <TASK>
[336740.908624] ? vmx_vcpu_run+0x32/0x1470 [kvm_intel]
[336740.908645] kvm_arch_vcpu_ioctl_run+0x8f3/0x1780 [kvm]
[336740.908739] ? vcpu_put+0x4a/0x70 [kvm]
[336740.908814] kvm_vcpu_ioctl+0x29b/0x6f0 [kvm]
[336740.908886] ? __fget_light+0xa7/0x130
[336740.908894] __x64_sys_ioctl+0x92/0xd0
[336740.908901] do_syscall_64+0x59/0x90
[336740.908906] ? exit_to_user_mode_prepare+0x49/0x1a0
[336740.908913] ? syscall_exit_to_user_mode+0x26/0x50
[336740.908918] ? do_syscall_64+0x69/0x90
[336740.908923] ? fpregs_assert_state_consistent+0x2a/0x50
[336740.908929] ? exit_to_user_mode_prepare+0x49/0x1a0
[336740.908934] ? syscall_exit_to_user_mode+0x26/0x50
[336740.908939] ? do_syscall_64+0x69/0x90
[336740.908943] ? irqentry_exit+0x3b/0x50
[336740.908947] ? sysvec_reschedule_ipi+0x85/0x130
[336740.908952] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[336740.908957] RIP: 0033:0x7fe2511423ab
[336740.908961] Code: 0f 1e fa 48 8b 05 e5 7a 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b5 7a 0d 00 f7 d8 64 89 01 48
[336740.908964] RSP: 002b:00007fe24cf315b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[336740.908969] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fe2511423ab
[336740.908972] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000014
[336740.908976] RBP: 000055d1523e12f0 R08: 000055d14fd0f270 R09: 00007fe2380040b8
[336740.908979] R10: 00007fe2380050a0 R11: 0000000000000246 R12: 0000000000000000
[336740.908981] R13: 000055d15037c080 R14: 00007fff7b2045c0 R15: 00007fe24cf31880
[336740.908989] </TASK>
[336740.908991] Modules linked in: ip6t_REJECT nf_reject_ipv6 nf_conntrack_netlink xfrm_user xfrm_algo rfcomm xt_addrtype br_netfilter nf_tables nfnetlink bridge stp llc overlay ip6table_filter ip6table_nat ip6table_mangle ip6_tables ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog xt_conntrack cmac algif_hash algif_skcipher iptable_filter af_alg bnep snd_soc_skl intel_rapl_msr snd_soc_hdac_hda snd_hda_ext_core mei_hdcp snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi intel_rapl_common snd_hda_codec_hdmi snd_soc_core snd_compress xt_MASQUERADE intel_tcc_cooling iwlmvm snd_hda_codec_realtek ac97_bus x86_pkg_temp_thermal snd_hda_codec_generic intel_powerclamp ledtrig_audio mac80211 snd_pcm_dmaengine coretemp libarc4 snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi btusb snd_hda_codec iptable_nat snd_hda_core btrtl iwlwifi nf_nat btbcm rapl snd_hwdep intel_cstate btintel nf_conntrack nf_defrag_ipv6 snd_pcm btmtk snd_timer snd nf_defrag_ipv4 iTCO_wdt bluetooth ee1004
[336740.909085] cfg80211 intel_pmc_bxt iTCO_vendor_support soundcore ecdh_generic 8250_dw ecc intel_xhci_usb_role_switch mei_me intel_pch_thermal mei ir_rc6_decoder rc_rc6_mce xt_CHECKSUM ite_cir acpi_pad mac_hid xt_tcpudp iptable_mangle kvm_intel kvm binfmt_misc sch_fq_codel ramoops msr reed_solomon pstore_blk pstore_zone efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear i915 drm_buddy i2c_algo_bit ttm drm_display_helper cec crct10dif_pclmul crc32_pclmul rc_core sdhci_pci ghash_clmulni_intel drm_kms_helper aesni_intel syscopyarea sysfillrect sysimgblt crypto_simd ahci fb_sys_fops cqhci intel_lpss_pci cryptd i2c_i801 drm intel_lpss xhci_pci e1000e i2c_smbus libahci idma64 sdhci xhci_pci_renesas video pinctrl_sunrisepoint
[336740.909183] CR2: 0000000000000098
[336740.909186] ---[ end trace 0000000000000000 ]---
[336740.909189] RIP: 0010:topa_full+0x6/0x60 [kvm_intel]
[336740.909210] Code: fc 5b 41 5c 5d c3 cc cc cc cc 65 8b 15 fb 36 34 3f 48 c7 c7 a5 cb ce c0 e8 ab 69 68 fc eb 90 0f 1f 44 00 00 0f 1f 44 00 00 55 <48> 8b 87 98 00 00 00 48 89 e5 a9 80 ff ff ff 75 1d 48 c1 e8 20 48
[336740.909213] RSP: 0018:ffffbc5a847c3c50 EFLAGS: 00010046
[336740.909217] RAX: 0000000000000000 RBX: ffff90e114577000 RCX: ffff90e1b20e2fc0
[336740.909220] RDX: ffff90e117df0100 RSI: ffffffffc0c21f4f RDI: 0000000000000000
[336740.909223] RBP: ffffbc5a847c3ca0 R08: 0000000016a7edac R09: 00000000001b775e
[336740.909226] R10: 00000000001b775e R11: fffddb3e539b56fc R12: ffff90e115fea8c0
[336740.909229] R13: 0000000000000000 R14: 0000000000000000 R15: ffff90e115fea8f8
[336740.909232] FS: 00007fe24cf32700(0000) GS:ffff90e46ec00000(0000) knlGS:0000000000000000
[336740.909236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[336740.909239] CR2: 0000000000000098 CR3: 000000012c498002 CR4: 00000000003726f0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes kAFL workers will raised an assertion failure message in
QEMU
:https://github.com/IntelLabs/kafl.qemu/blob/kafl_stable/nyx/pt.c#L327
This is due to an failed allocation in the linux kernel, and looking at dmesg logs, a few messages
like
Cannot allocate main ToPA buffer!
appears.These messages originates from here:
https://github.com/IntelLabs/kafl.linux/blob/kvm-nyx-5.10.73/arch/x86/kvm/vmx/vmx_pt.c#LL775C15-L775C48
A possible fix is to drop your kernel file cache:
The flag
__GFP_NOWARN
might be in question for this allocation failure.See also kernel memory allocation guide
The text was updated successfully, but these errors were encountered: