Trying to recompile kernel in order to enable rfcomm support #26
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit fd5de27 upstream. As kernelci.org reports, this function is not used in vdk_hs38_defconfig: arch/arc/kernel/unwind.c:188:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function] Fixes: bc79c9a ("ARC: dw2 unwind: Reinstante unwinding out of modules") Link: https://kernelci.org/build/id/5d1cae3f59b514300340c132/logs/ Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4f18d86 upstream. The stfle inline assembly returns the number of double words written (condition code 0) or the double words it would have written (condition code 3), if the memory array it got as parameter would have been large enough. The current stfle implementation assumes that the array is always large enough and clears those parts of the array that have not been written to with a subsequent memset call. If however the array is not large enough memset will get a negative length parameter, which means that memset clears memory until it gets an exception and the kernel crashes. To fix this simply limit the maximum length. Move also the inline assembly to an extra function to avoid clobbering of register 0, which might happen because of the added min_t invocation together with code instrumentation. The bug was introduced with commit 14375bc ("[S390] cleanup facility list handling") but was rather harmless, since it would only write to a rather large array. It became a potential problem with commit 3ab121a ("[S390] kernel: Add z/VM LGR detection"). Since then it writes to an array with only four double words, while some machines already deliver three double words. As soon as machines have a facility bit within the fifth double a crash on IPL would happen. Fixes: 14375bc ("[S390] cleanup facility list handling") Cc: <[email protected]> # v2.6.37+ Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e54e478 upstream. When tiqdio_remove_input_queues() removes a queue from the tiq_list as part of qdio_shutdown(), it doesn't re-initialize the queue's list entry and the prev/next pointers go stale. If a subsequent qdio_establish() fails while sending the ESTABLISH cmd, it calls qdio_shutdown() again in QDIO_IRQ_STATE_ERR state and tiqdio_remove_input_queues() will attempt to remove the queue entry a second time. This dereferences the stale pointers, and bad things ensue. Fix this by re-initializing the list entry after removing it from the list. For good practice also initialize the list entry when the queue is first allocated, and remove the quirky checks that papered over this omission. Note that prior to commit e521813 ("s390/qdio: fix access to uninitialized qdio_q fields"), these checks were bogus anyway. setup_queues_misc() clears the whole queue struct, and thus needs to re-init the prev/next pointers as well. Fixes: 779e6e1 ("[S390] qdio: new qdio driver.") Cc: <[email protected]> Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit ac6639c upstream. Current code sets the dsci to 0x00000080. Which doesn't make any sense, as the indicator area is located in the _left-most_ byte. Worse: if the dsci is the _shared_ indicator, this potentially clears the indication of activity for a _different_ device. tiqdio_thinint_handler() will then have no reason to call that device's IRQ handler, and the device ends up stalling. Fixes: d0c9d4a ("[S390] qdio: set correct bit in dsci") Cc: <[email protected]> Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 250715a upstream. The syzkaller folks reported a NULL pointer dereference that seems to be cause by a race between KVM_CREATE_IRQCHIP and KVM_CREATE_PIT2. The former takes kvm->lock (except when registering the devices, which needs kvm->slots_lock); the latter takes kvm->slots_lock only. Change KVM_CREATE_PIT2 to follow the same model as KVM_CREATE_IRQCHIP. Testcase: #include <pthread.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> #include <stdint.h> #include <string.h> #include <stdlib.h> #include <sys/syscall.h> #include <unistd.h> long r[23]; void* thr1(void* arg) { struct kvm_pit_config pitcfg = { .flags = 4 }; switch ((long)arg) { case 0: r[2] = open("/dev/kvm", O_RDONLY|O_ASYNC); break; case 1: r[3] = ioctl(r[2], KVM_CREATE_VM, 0); break; case 2: r[4] = ioctl(r[3], KVM_CREATE_IRQCHIP, 0); break; case 3: r[22] = ioctl(r[3], KVM_CREATE_PIT2, &pitcfg); break; } return 0; } int main(int argc, char **argv) { long i; pthread_t th[4]; memset(r, -1, sizeof(r)); for (i = 0; i < 4; i++) { pthread_create(&th[i], 0, thr, (void*)i); if (argc > 1 && rand()%2) usleep(rand()%1000); } usleep(20000); return 0; } Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Radim Krčmář <[email protected]> Signed-off-by: Zubin Mithra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changes in 4.4.186: (41 commits)
Input: elantech - enable middle button support on 2 ThinkPads
samples, bpf: fix to change the buffer size for read()
mac80211: mesh: fix RCU warning
mwifiex: Fix possible buffer overflows at parsing bss descriptor
dt-bindings: can: mcp251x: add mcp25625 support
can: mcp251x: add support for mcp25625
Input: imx_keypad - make sure keyboard can always wake up system
ARM: davinci: da850-evm: call regulator_has_full_constraints()
ARM: davinci: da8xx: specify dma_coherent_mask for lcdc
md: fix for divide error in status_resync
bnx2x: Check if transceiver implements DDM before access
udf: Fix incorrect final NOT_ALLOCATED (hole) extent length
x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg()
x86/tls: Fix possible spectre-v1 in do_get_thread_area()
mwifiex: Abort at too short BSS descriptor element
mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()
fscrypt: don't set policy for a dead directory
mwifiex: Don't abort on small, spec-compliant vendor IEs
USB: serial: ftdi_sio: add ID for isodebug v1
USB: serial: option: add support for GosunCn ME3630 RNDIS mode
usb: gadget: ether: Fix race between gether_disconnect and rx_submit
usb: renesas_usbhs: add a workaround for a race condition of workqueue
staging: comedi: dt282x: fix a null pointer deref on interrupt
staging: comedi: amplc_pci230: fix null pointer deref on interrupt
carl9170: fix misuse of device driver API
VMCI: Fix integer overflow in VMCI handle arrays
MIPS: Remove superfluous check for __linux__
e1000e: start network tx queue only when link is up
perf/core: Fix perf_sample_regs_user() mm check
ARM: omap2: remove incorrect __init annotation
be2net: fix link failure after ethtool offline test
ppp: mppe: Add softdep to arc4
sis900: fix TX completion
dm verity: use message limit for data block corruption message
kvm: x86: avoid warning on repeated KVM_SET_TSS_ADDR
ARC: hide unused function unw_hdr_alloc
s390: fix stfle zero padding
s390/qdio: (re-)initialize tiqdio list entries
s390/qdio: don't touch the dsci in tiqdio_add_input_queues()
KVM: x86: protect KVM_CREATE_PIT/KVM_CREATE_PIT2 with kvm->lock
Linux 4.4.186
Signed-off-by: Nathan Chancellor <[email protected]>
Conflicts:
fs/f2fs/crypto_policy.c
pkt->msg_size can be corrupted and that leads to OOB access. So added additional conditional check to avoid OOB access in debug queue packet handling. Change-Id: I360812c40369ecef2dd99464d400661bc785074b Signed-off-by: Govindaraj Rajagopal <[email protected]> Signed-off-by: Sanjay Singh <[email protected]>
As param_size is included in apr header pkt_size, out of bounds access occurs in glink. Remove the param size addition to fix this issue. CRs-Fixed: 2472208 Change-Id: If8b34aeacd3bc9ba67ac9276eb1a8ebf0933f9f9 Signed-off-by: Aditya Bavanari <[email protected]>
Proper buffer length check is missing for dci userspace data buffer before processing the dci transaction. The patch adds proper check for the same. Change-Id: I68c0e8c41d4e05493adecf8a1fcacea708dfafa2 Signed-off-by: Hardik Arya <[email protected]>
validate structures and payload sizes in the packet against packet size to avoid OOB access. Change-Id: Id44e5c6be4dde3e6545d453f5edd3219776a4e58 Signed-off-by: Manikanta Kanamarlapudi <[email protected]> Signed-off-by: Sanjay Singh <[email protected]>
Use trusted packet size on the received packet and check for the size of the data received against the expected size before accessing the packet. Change-Id: I1bd6008249a0bf4edeec711ec8d23cf7b8dac1f1 Signed-off-by: Priyanka Gujjula <[email protected]>
Change-Id: Ia610531b8fc48e6be35fc87ab6161d25aad35603
Make the f2fs implementation of FS_IOC_SETFLAGS use the new VFS helper function vfs_ioc_setflags_prepare(). This is based on a patch from Darrick Wong, but reworked to apply after commit 3609855 ("f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags"). Originally-from: Darrick J. Wong <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Chao Yu <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
Now that f2fs_ioc_setflags() and f2fs_ioc_fssetxattr() call the VFS helper functions which check for permission to change the immutable and append-only flags, it's no longer needed to do this check in f2fs_setflags_common() too. So remove it. This is based on a patch from Darrick Wong, but reworked to apply after commit 3609855 ("f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags"). Originally-from: Darrick J. Wong <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Chao Yu <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
f2fs_allocate_data_block() invalidates old block address and enable new block address. Then, if we try to read old block by f2fs_submit_page_bio(), it will give WARN due to reading invalid blocks. Let's make the order sanely back. Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
The kernel mount_block_root() function expects -EACESS or -EINVAL for a unmountable filesystem when trying to mount the root with different filesystem types. However, in 5.3-rc1 the behavior when F2FS code cannot find valid block changed to return -EFSCORRUPTED(-EUCLEAN), and this error code makes mount_block_root() fail when trying to probe F2FS. When the magic number of the superblock mismatches, it has a high probability that it's just not a F2FS. In this case return -EINVAL seems to be a better result, and this return value can make mount_block_root() probing work again. Return -EINVAL when the superblock has magic mismatch, -EFSCORRUPTED in other cases (the magic matches but the superblock cannot be recognized). Fixes: 10f966b ("f2fs: use generic EFSBADCRC/EFSCORRUPTED") Signed-off-by: Icenowy Zheng <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
drawobj_destroy_sync() tries to cancel all pending sync events by taking local copy of pending list. In case of sync point timestamp event, it goes ahead and accesses context's events list assuming that event's context would be alive. But at the same time, if the other context, which is of interest for these sync point events, can be destroyed by cancelling all events in its group. This leads to use-after-free in drawobj_destroy_sync() path. Fix is to give the responsibility of putting the context's ref count to the thread which clears the pending mask. Change-Id: I8d08ef6ddb38ca917f75088071c04727bced11d2 Signed-off-by: Rajesh Kemisetti <[email protected]>
Added missing lock to avoid race conditon for dqbuf and streamon. Change-Id: I260dfc964066ad68552dfab0c43584708cfc8b8e Signed-off-by: E V Ravi <[email protected]>
…roy" into kernel.lnx.4.4.r34-rel
[ Upstream commit db13a5b ] While trying to get the uart with parity working I found setting even parity enabled odd parity insted. Fix the register settings to match the datasheet of AR9331. A similar patch was created by 8devices, but not sent upstream. 8devices/openwrt-8devices@77c5586 Signed-off-by: Stefan Hellermann <[email protected]> Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 1196364 ] calc_vmlinuz_load_addr.c requires SZ_64K to be defined for alignment purposes. It included "../../../../include/linux/sizes.h" to define that size, however "sizes.h" tries to include <linux/const.h> which assumes linux system headers. These may not exist eg. the following error was encountered when building Linux for OpenWrt under macOS: In file included from arch/mips/boot/compressed/calc_vmlinuz_load_addr.c:16: arch/mips/boot/compressed/../../../../include/linux/sizes.h:11:10: fatal error: 'linux/const.h' file not found ^~~~~~~~~~ Change makefile to force building on local linux headers instead of system headers. Also change eye-watering relative reference in include file spec. Thanks to Jo-Philip Wich & Petr Štetiar for assistance in tracking this down & fixing. Suggested-by: Jo-Philipp Wich <[email protected]> Signed-off-by: Petr Štetiar <[email protected]> Signed-off-by: Kevin Darbyshire-Bryant <[email protected]> Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 2b8066c ] If probe() fails anywhere beyond the point where sdma_get_firmware() is called, then a kernel oops may occur. Problematic sequence of events: 1. probe() calls sdma_get_firmware(), which schedules the firmware callback to run when firmware becomes available, using the sdma instance structure as the context 2. probe() encounters an error, which deallocates the sdma instance structure 3. firmware becomes available, firmware callback is called with deallocated sdma instance structure 4. use after free - kernel oops ! Solution: only attempt to load firmware when we're certain that probe() will succeed. This guarantees that the firmware callback's context will remain valid. Note that the remove() path is unaffected by this issue: the firmware loader will increment the driver module's use count, ensuring that the module cannot be unloaded while the firmware callback is pending or running. Signed-off-by: Sven Van Asbroeck <[email protected]> Reviewed-by: Robin Gong <[email protected]> [vkoul: fixed braces for if condition] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 97354f2 ] Currently mac80211 do not support probe response template for mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host driver tries to configure probe response template for mesh, but it fails because the interface type is not NL80211_IFTYPE_AP but NL80211_IFTYPE_MESH_POINT. To avoid this failure, skip sending probe response template to firmware for mesh point. Tested HW: WCN3990/QCA6174/QCA9984 Signed-off-by: Surabhi Vishnoi <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Knowing if a fence has been signaled is useful for avoiding the overhead of needlessly setting up a sync operation. Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
Trying to wait for fences that have already been signaled incurs a high setup cost, since dynamic memory allocation must be used. Avoiding this overhead when it isn't needed improves performance. Signed-off-by: Sultan Alsawaf <[email protected]>
The memory allocated dynamically here is just used to store a single instance of a struct. Allocate both possible structs on the stack instead of allocating them dynamically to improve performance. These structs also do not need to be zeroed out. Signed-off-by: Sultan Alsawaf <[email protected]>
All of these dynamically-allocated structs can be simply placed on the stack, eliminating the overhead of dynamic memory allocation entirely. Signed-off-by: Sultan Alsawaf <[email protected]>
When a domain context is initialized, pgtbl ops are allocated, but they aren't freed when the domain context is destroyed, causing memory to be leaked. Fix the memory leak by freeing pgtbl ops when domain contexts are destroyed. Signed-off-by: Sultan Alsawaf <[email protected]>
Every atomic frame commit allocates memory dynamically for the destination scaler, when those allocations can just be stored on the stack instead. Eliminate these dynamic memory allocations in the frame commit path to improve performance. Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
In order to prevent redundant entry creation by racing against itself, mb2_cache_entry_create scans through a large hash-list of all current entries in order to see if another allocation for the requested new entry has been made. Furthermore, it allocates memory for a new entry before scanning through this hash-list, which results in that allocated memory being discarded when the requested new entry is already present. This happens more than half the time. Speed up cache entry creation by keeping a small linked list of requested new entries in progress, and scanning through that first instead of the large hash-list. Additionally, don't bother allocating memory for a new entry until it's known that the allocated memory will be used. Signed-off-by: Sultan Alsawaf <[email protected]>
The allocation context structure is quite small and easily fits on the stack. There's no need to allocate it dynamically. Signed-off-by: Sultan Alsawaf <[email protected]>
The stack frame size warning can be deceptive when it is clear that a function with a large frame size won't cause stack overflows given how it is used. Since this warning is more of a nuisance rather than helpful, disable it. Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
Most command buffers here are rather small (fewer than 256 words); it's a waste of time to dynamically allocate memory for such a small buffer when it could easily fit on the stack. Conditionally using an on-stack command buffer when the size is small enough eliminates the need for using a dynamically-allocated buffer most of the time, reducing GPU command submission latency. Signed-off-by: Sultan Alsawaf <[email protected]>
Most write buffers are rather small and can fit on the stack, eliminating the need to allocate them dynamically. Reserve a 4 KiB stack buffer for this purpose to avoid the overhead of dynamic memory allocation. Signed-off-by: Sultan Alsawaf <[email protected]>
Most context buffers are rather small and can fit on the stack, eliminating the need to allocate them dynamically. Reserve a 4 KiB stack buffer for this purpose to avoid the overhead of dynamic memory allocation. Signed-off-by: Sultan Alsawaf <[email protected]>
32 bytes for the on-stack file name buffer is rather small and doesn't fit many file names, causing dynamic allocation to be used more often than necessary instead. Increasing the on-stack buffer to 4 KiB is safe and helps this function avoid dynamic memory allocations far more frequently. Signed-off-by: Sultan Alsawaf <[email protected]>
There's no reason to dynamically allocate memory for a single, small struct instance (output_layer) when it can be allocated on the stack. Additionally, layer_list and validate_info_list are limited by the maximum number of layers allowed, so they can be replaced by stack allocations. Signed-off-by: Sultan Alsawaf <[email protected]>
The temporary command buffer in _set_pagetable_gpu is only the size of a single page; it is therefore easy to replace the dynamic command buffer allocation with a static one to improve performance by avoiding the latency of dynamic memory allocation. Signed-off-by: Sultan Alsawaf <[email protected]>
Try to use an on-stack buffer for memory allocations that are small enough to not warrant a dynamic allocation, and eliminate dynamic memory allocation entirely in msm_camera_cci_i2c_read_seq. This improves performance by skipping latency-prone dynamic memory allocation when it isn't needed. Signed-off-by: Sultan Alsawaf <[email protected]>
We have a 16 KiB stack; buffers of 4 KiB and 512 B work perfectly fine in place of a small 128-byte buffer and especially no on-stack buffer at all. This avoids dynamic memory allocation more often, improving performance, and it's safe according to stack usage measurements at runtime. Signed-off-by: Sultan Alsawaf <[email protected]>
Since the fence info ioctl limits output data length to 4096 bytes, we can just use a 4096-byte on-stack buffer for it (which is confirmed to be safe via runtime stack usage measurements). This ioctl is used for every frame rendered to the display, so eliminating dynamic memory allocation overhead here improves frame rendering performance. Signed-off-by: Sultan Alsawaf <[email protected]>
The dynamic memory allocations in load_elf_binary can be replaced by large stack allocations that bring the total frame size for the function up to about 4 KiB. We have 16 KiB of stack space, and runtime measurements confirm that using this much stack memory here is safe. This improves performance by eliminating the overhead of dynamic memory allocation. Signed-off-by: Sultan Alsawaf <[email protected]>
Although the maximum xattr size is too big to fit on the stack (64 KiB), we can still fulfill most getxattr requests with a 4 KiB stack allocation, thereby improving performance. Such a large stack allocation here is confirmed to be safe via stack usage measurements at runtime. Signed-off-by: Sultan Alsawaf <[email protected]>
Although path depth is unbounded, we can still fulfill many path allocations here with a 4 KiB stack allocation, thereby improving performance. Signed-off-by: Sultan Alsawaf <[email protected]>
The derived keys are usually quite small (48 B). We can use a small on-stack buffer of 1 KiB to dodge dynamic memory allocation, speeding up heh_setkey. Signed-off-by: Sultan Alsawaf <[email protected]>
The system heap allocation process consists of allocating numerous temporary buffers that can instead be placed on the stack, to an extent; if the new 4 KiB on-stack buffer runs out, page_info allocations will fall back to using kmalloc. Additionally, since system heap allocations are frequent, they can benefit from the use of a memory pool for allocating the persistent sg_table structures. These allocations, along with a few others, also don't need to be zeroed out. These changes improve system heap allocation performance considerably. Signed-off-by: Sultan Alsawaf <[email protected]>
The environment buffer isn't very big; when it's allocated on the stack, kobject_uevent_env's stack frame size increases to just over 2 KiB, which is safe considering that we have a 16 KiB stack. Allocate the environment buffer on the stack instead of using the slab allocator in order to improve performance. Signed-off-by: Sultan Alsawaf <[email protected]>
Since this 4 KiB name buffer is only used temporarily, allocate it on the stack to improve performance. This is confirmed to be safe according to runtime stack usage measurements. Signed-off-by: Sultan Alsawaf <[email protected]>
Most dentry allocations exceed 32B. Increase it by 192 bytes to accommodate larger allocation requests. This still ensures 64 bytes cacheline alignments. Signed-off-by: Park Ju Hyung <[email protected]>
Most allocations done here are rather small and can fit on the stack, eliminating the need to allocate them dynamically. Reserve a 1024B stack buffer for this purpose to avoid the overhead of dynamic memory allocation. 1024B covers most use cases, and higher values were observed to cause stack corruptions. Co-authored-by: Sultan Alsawaf <[email protected]> Signed-off-by: Park Ju Hyung <[email protected]>
context_struct_to_string() contains expensive kmalloc() calls. In most cases, there's no purpose in calling context_struct_to_string() on !CONFIG_AUDIT as logs won't be saved anyways. Signed-off-by: Park Ju Hyung <[email protected]>
For temporary usage such as logging, there's no need to allocate a dedicated memory. Signed-off-by: Park Ju Hyung <[email protected]>
Signed-off-by: Park Ju Hyung <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello
I'm trying to recompile the android_kernel_oneplus_msm8998 in order to enable RFCOMM support.
I have followed the following instrustions:
https://github.com/offensive-security/kali-nethunter/wiki/Porting-Nethunter
https://github.com/offensive-security/kali-nethunter/wiki/Modifying-the-Kernel
But when i try to make oneplus5-stock_defconfig i get the following error:
`root@ubuntu-VirtualBox:/home/ubuntu/Downloads/new-kernel/android_kernel_oneplus_msm8998# make oneplus5-stock_defconfig
./scripts/gcc-version.sh: line 25: /home/arter97/arm64-gcc/bin/aarch64-elf-gcc: No such file or directory
./scripts/gcc-version.sh: line 26: /home/arter97/arm64-gcc/bin/aarch64-elf-gcc: No such file or directory
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/bin2c
configuration written to .config
`
The directory /home/arter97/arm64-gcc/bin/aarch64-elf-gcc doesn't exist on my pc. Have you any idea what am i doing wrong???
Or maybe you could give some instructions how to recompile kernel.