summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
| * | ALSA: rawmidi: Avoid OOB access to runtime bufferAlexander Grund2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware and application ptrs must be less than buffer_size or there will be an out-of-bound access as they are used as offsets into the buffer. Additionally the difference between buffer_size and those pointers is taken and passed to `memcpy` which would turn the negative value into a large positive value also overflowing the buffer. This can happen if the new buffer_size of the ioctl is less than the old one which updates buffer_size but does not reset the ptrs. Contained in 01b6ca65e10f2 ("ALSA: rawmidi: Change resized buffers atomically") but lost due to a merge conflict with 742017e8de6a8 ("ANDROID: sound: rawmidi: Hold lock around realloc") Fixes: 08e780103611f ("Merge branch 'android-4.4-p'") Change-Id: Ibc0e1ae3eb8691d5865e2146367699ac119d6935
| * | HID: check empty report_list in hid_validate_values()Pietro Borrello2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b12fece4c64857e5fab4290bf01b2e0317a88456 ] Add a check for empty report_list in hid_validate_values(). The missing check causes a type confusion when issuing a list_entry() on an empty report_list. The problem is caused by the assumption that the device must have valid report_list. While this will be true for all normal HID devices, a suitably malicious device can violate the assumption. Fixes: 1b15d2e5b807 ("HID: core: fix validation of report id 0") Change-Id: I990e3685de15a63e636a008dce7c450966c47cf8 Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
| * | HID: core: Provide new max_buffer_size attribute to over-ride the defaultLee Jones2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc upstream. Presently, when a report is processed, its proposed size, provided by the user of the API (as Report Size * Report Count) is compared against the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some low-level HID drivers allocate a reduced amount of memory to their buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending this check inadequate in some cases. In these circumstances, if the received report ends up being smaller than the proposed report size, the remainder of the buffer is zeroed. That is, the space between sizeof(csize) (size of the current report) and the rsize (size proposed i.e. Report Size * Report Count), which can be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset() shoots straight past the end of the buffer boundary and starts zeroing out in-use values, often resulting in calamity. This patch introduces a new variable into 'struct hid_ll_driver' where individual low-level drivers can over-ride the default maximum value of HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the interface. Change-Id: I851ac2340e107f57aded660540218c693e0e73f4 Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> [Lee: Backported to v4.14.y] Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
| * | HID: core: fix shift-out-of-bounds in hid_report_raw_eventZhangPeng2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ec61b41918587be530398b0d1c9a0d16619397e5 upstream. Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. Reported-by: syzbot+8b1641d2f14732407e23@syzkaller.appspotmail.com Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Change-Id: Ieffc79279df91b52fcfa087a043835f08e2c2af8 Signed-off-by: ZhangPeng <zhangpeng362@huawei.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
| * | tty: use new tty_insert_flip_string_and_push_buffer() in pty_write()Jiri Slaby2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a501ab75e7624d133a5a3c7ec010687c8b961d23 upstream. There is a race in pty_write(). pty_write() can be called in parallel with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to the buffer. Provided, tty_flip_buffer_push() in pty_write() is called outside the lock, it can commit inconsistent tail. This can lead to out of bounds writes and other issues. See the Link below. To fix this, we have to introduce a new helper called tty_insert_flip_string_and_push_buffer(). It does both tty_insert_flip_string() and tty_flip_buffer_commit() under the port lock. It also calls queue_work(), but outside the lock. See 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write) for the reasons. Keep the helper internal-only (in drivers' tty.h). It is not intended to be used widely. Link: https://seclists.org/oss-sec/2022/q2/155 Fixes: 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write) Change-Id: I1f08439cc9047ee56df0681c3dfc5cd18f4b5a37
| * | tty: extract tty_flip_buffer_commit() from tty_flip_buffer_push()Jiri Slaby2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 716b10580283fda66f2b88140e3964f8a7f9da89 upstream. We will need this new helper in the next patch. Cc: Hillf Danton <hdanton@sina.com> Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Change-Id: Iff30e1534948b64bf060c2b0ac290e541e4194b4 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Alex: Adjust to changing tty_schedule_flip instead of tty_flip_buffer_push
| * | tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_lineYang Jihong2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream. print_trace_line may overflow seq_file buffer. If the event is not consumed, the while loop keeps peeking this event, causing a infinite loop. Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: stable@vger.kernel.org Fixes: 088b1e427dbba ("ftrace: pipe fixes") Change-Id: Ic7f41111b7c7944e9f64b010a3c1ff095c757b9d Signed-off-by: Yang Jihong <yangjihong1@huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
| * | tracing: Fix memleak due to race between current_tracer and traceZheng Yejian2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit eecb91b9f98d6427d4af5fdb8f108f52572a39e7 ] Kmemleak report a leak in graph_trace_open(): unreferenced object 0xffff0040b95f4a00 (size 128): comm "cat", pid 204981, jiffies 4301155872 (age 99771.964s) hex dump (first 32 bytes): e0 05 e7 b4 ab 7d 00 00 0b 00 01 00 00 00 00 00 .....}.......... f4 00 01 10 00 a0 ff ff 00 00 00 00 65 00 10 00 ............e... backtrace: [<000000005db27c8b>] kmem_cache_alloc_trace+0x348/0x5f0 [<000000007df90faa>] graph_trace_open+0xb0/0x344 [<00000000737524cd>] __tracing_open+0x450/0xb10 [<0000000098043327>] tracing_open+0x1a0/0x2a0 [<00000000291c3876>] do_dentry_open+0x3c0/0xdc0 [<000000004015bcd6>] vfs_open+0x98/0xd0 [<000000002b5f60c9>] do_open+0x520/0x8d0 [<00000000376c7820>] path_openat+0x1c0/0x3e0 [<00000000336a54b5>] do_filp_open+0x14c/0x324 [<000000002802df13>] do_sys_openat2+0x2c4/0x530 [<0000000094eea458>] __arm64_sys_openat+0x130/0x1c4 [<00000000a71d7881>] el0_svc_common.constprop.0+0xfc/0x394 [<00000000313647bf>] do_el0_svc+0xac/0xec [<000000002ef1c651>] el0_svc+0x20/0x30 [<000000002fd4692a>] el0_sync_handler+0xb0/0xb4 [<000000000c309c35>] el0_sync+0x160/0x180 The root cause is descripted as follows: __tracing_open() { // 1. File 'trace' is being opened; ... *iter->trace = *tr->current_trace; // 2. Tracer 'function_graph' is // currently set; ... iter->trace->open(iter); // 3. Call graph_trace_open() here, // and memory are allocated in it; ... } s_start() { // 4. The opened file is being read; ... *iter->trace = *tr->current_trace; // 5. If tracer is switched to // 'nop' or others, then memory // in step 3 are leaked!!! ... } To fix it, in s_start(), close tracer before switching then reopen the new tracer after switching. And some tracers like 'wakeup' may not update 'iter->private' in some cases when reopen, then it should be cleared to avoid being mistakenly closed again. Link: https://lore.kernel.org/linux-trace-kernel/20230817125539.1646321-1-zhengyejian1@huawei.com Fixes: d7350c3f4569 ("tracing/core: make the read callbacks reentrants") Change-Id: I1265ac4538ca529fb02b4cce76a4aa835f90b128 Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli@kernel.org>
| * | tracing: Ensure trace buffer is at least 4096 bytes largeSven Schnelle2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7acf3a127bb7c65ff39099afd78960e77b2ca5de ] Booting the kernel with 'trace_buf_size=1' give a warning at boot during the ftrace selftests: [ 0.892809] Running postponed tracer tests: [ 0.892893] Testing tracer function: [ 0.901899] Callback from call_rcu_tasks_trace() invoked. [ 0.983829] Callback from call_rcu_tasks_rude() invoked. [ 1.072003] .. bad ring buffer .. corrupted trace buffer .. [ 1.091944] Callback from call_rcu_tasks() invoked. [ 1.097695] PASSED [ 1.097701] Testing dynamic ftrace: .. filter failed count=0 ..FAILED! [ 1.353474] ------------[ cut here ]------------ [ 1.353478] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:1951 run_tracer_selftest+0x13c/0x1b0 Therefore enforce a minimum of 4096 bytes to make the selftest pass. Link: https://lkml.kernel.org/r/20220214134456.1751749-1-svens@linux.ibm.com Change-Id: I796709bd9ccaefb463da0aca49f53a475b5f57a0 Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * | tracing: Fix tp_printk option related with tp_printk_stop_on_bootJaeSang Yoo2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3203ce39ac0b2a57a84382ec184c7d4a0bede175 ] The kernel parameter "tp_printk_stop_on_boot" starts with "tp_printk" which is the same as another kernel parameter "tp_printk". If "tp_printk" setup is called before the "tp_printk_stop_on_boot", it will override the latter and keep it from being set. This is similar to other kernel parameter issues, such as: Commit 745a600cf1a6 ("um: console: Ignore console= option") or init/do_mounts.c:45 (setup function of "ro" kernel param) Fix it by checking for a "_" right after the "tp_printk" and if that exists do not process the parameter. Link: https://lkml.kernel.org/r/20220208195421.969326-1-jsyoo5b@gmail.com Change-Id: I997201f383889388231894b1881ead904e322b14 Signed-off-by: JaeSang Yoo <jsyoo5b@gmail.com> [ Fixed up change log and added space after if condition ] Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
| * | blktrace: Fix output non-blktrace event when blk_classic option enabledYang Jihong2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f596da3efaf4130ff61cd029558845808df9bf99 ] When the blk_classic option is enabled, non-blktrace events must be filtered out. Otherwise, events of other types are output in the blktrace classic format, which is unexpected. The problem can be triggered in the following ways: # echo 1 > /sys/kernel/debug/tracing/options/blk_classic # echo 1 > /sys/kernel/debug/tracing/events/enable # echo blk > /sys/kernel/debug/tracing/current_tracer # cat /sys/kernel/debug/tracing/trace_pipe Fixes: c71a89615411 ("blktrace: add ftrace plugin") Change-Id: Ia8eda6f8123933ae2b8219fc781d417be8711647 Signed-off-by: Yang Jihong <yangjihong1@huawei.com> Link: https://lore.kernel.org/r/20221122040410.85113-1-yangjihong1@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
| * | msm: kgsl: Prevent wrap around during user address mappingMohammed Mirza Mandayappurath Manzoor2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When setting svm region during the gpuobj import ioctl call for a usermem address, there is a possibility of a very large input size causing the region's 64-bit end address to wrap around. This can cause the region to incorrectly be considered valid, ultimately allowing a use after free scenario. To prevent this, detect the occurrence of a wrap and reject the import. Change-Id: I4a88f56c58b830d4342e47dc1d1f6290c78ab6b4 Signed-off-by: Mohammed Mirza Mandayappurath Manzoor <quic_mmandaya@quicinc.com>
| * | iommu: Fix missing return check of arm_lpae_init_ptePratyush Brahma2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UAF scenario may occur in clients with EL1 privileges for iova mappings when we miss to check the return value of arm_lpae_init_pte which may lead to an PTE be counted as it was set even if it was already existing. This can cause a dangling IOMMU PTE to be left mapped pointing to a freed object and cause UAF in the client if the dangling PTE is accessed after a failed unmap operation. Fixes: 27de1978c331 ("ANDROID: GKI: iommu/io-pgtable-arm: LPAE related updates by vendor") Change-Id: I674b9b520e705b8f8e63ba20ed76e64cb2fe0f47 Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com> (cherry picked from commit b1405fc833e94c7b69fd4a63ed204407284a58dc)
| * | q6asm: validate payload size before accessSoumya Managoli2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | Payload size is not checked before payload access. Check size to avoid out-of-boundary memory access. Change-Id: I1bd8281ad263b8c0102335504a740312755b8d15 Signed-off-by: Shalini Manjunatha <quic_c_shalma@quicinc.com> Signed-off-by: Soumya Managoli <quic_c_smanag@quicinc.com>
| * | dsp: afe: Add check for sidetone iir config copy size.Soumya Managoli2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | Avoid OOB access of sidetone iir config array when iir_num_biquad_stages returned from cal block is > 10 Change-Id: I45b95e8bdd1a993a526590c94cf2f9a85c12af37 Signed-off-by: Soumya Managoli <quic_c_smanag@quicinc.com>
| * | q6core: Avoid OOB access in q6coreSoumya Managoli2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "num_services", a signed integer when compared with constant results in conversion of signed integer to max possible unsigned int value when "num_services" is a negative value. This can lead to OOB read. Fix is to handle this case. Change-Id: Id6a8f150d9019c972a87f789e4c626337a97bfff Signed-off-by: Soumya Managoli <quic_c_smanag@quicinc.com>
| * | q6voice: Add buf size check for cvs cal data.Soumya Managoli2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check for the max size of cvs command register calibration data that can be copied else will result in buffer overflow. Change-Id: Id7a4c5a9795143798b68dfde779f17fb450e3848 Signed-off-by: Soumya Managoli <quic_c_smanag@quicinc.com> (cherry picked from commit 606e2a66f0cd284cfe0d445230b45430b99578e8)
| * | ASoC: msm-pcm-host-voice: Handle OOB access in hpcm_start.Soumya Managoli2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no error check for case when hpcm_start is called for the same RX or TX tap points multiple times. This can result in OOB access of struct vss_ivpcm_tap_point. Handle this scenario with appropriate no_of_tp check. Change-Id: Ib384d21c9bf372f3e5d78f64b5c056e836728399 Signed-off-by: Soumya Managoli <quic_c_smanag@quicinc.com> (cherry picked from commit 521277c4c3ffc4a3f4a232de41cfa4fc7b6aaa35)
| * | Asoc: check for invalid voice session idSaurav Kumar2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | Add check to return if session id is invalid. Change-Id: Ida0e07b78657102a3bf6e73a1ca23c44ad112426 Signed-off-by: Lakshman Chaluvaraju <lchalu@codeaurora.org> Signed-off-by: Tapas Dey <quic_tapadey@quicinc.com>
| * | kconfig: display recursive dependency resolution hint just onceMasahiro Yamada2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1c199f2878f6 ("kbuild: document recursive dependency limitation / resolution") probably intended to show a hint along with "recursive dependency detected!" error, but it missed to add {...} guard, and the hint is displayed in every loop of the dep_stack traverse, annoyingly. This error was detected by GCC's -Wmisleading-indentation when switching to build-time generation of lexer/parser. scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’: scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (stack->sym == last_sym) ^~ scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n"); ^~~~~~~ I could simply add {...} to surround the three fprintf(), but I rather chose to move the hint after the loop to make the whole message readable. Fixes: 1c199f2878f6 ("kbuild: document recursive dependency limitation / resolution" Change-Id: I87e5440b694922b79fc5b8ba0800ec4fa245be01 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
| * | wireguard: version: bumpJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Bruno Martins <bgcngm@gmail.com> Change-Id: I41c7efda7df90f5920f4512c04bc57d23742f142
| * | compat: handle backported rng and blake2sJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I02feaa08c8e6194933bb1952fda70d8935fc8043
| * | qemu: set panic_on_warn=1 from cmdlineJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than setting this once init is running, set panic_on_warn from the kernel command line, so that it catches splats from WireGuard initialization code and the various crypto selftests. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I332e5e69de3d4a54b8defa97bd58052c35999462
| * | qemu: use vports on armJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | Rather than having to hack up QEMU, just use the virtio serial device. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I5bc7844746a131ff61ae637c5fa60dbb09e033ca
| * | device: check for metadata_dst with skb_valid_dst()Nikolay Aleksandrov2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we try to transmit an skb with md_dst attached through wireguard we hit a null pointer dereference in wg_xmit() due to the use of dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to dereference dst->dev. Since wireguard doesn't use md_dsts we should use skb_valid_dst(), which checks for DST_METADATA flag, and if it's set, then falls back to wireguard's device mtu. That gives us the best chance of transmitting the packet; otherwise if the blackhole netdev is used we'd get ETH_MIN_MTU. [ 263.693506] BUG: kernel NULL pointer dereference, address: 00000000000000e0 [ 263.693908] #PF: supervisor read access in kernel mode [ 263.694174] #PF: error_code(0x0000) - not-present page [ 263.694424] PGD 0 P4D 0 [ 263.694653] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 263.694876] CPU: 5 PID: 951 Comm: mausezahn Kdump: loaded Not tainted 5.18.0-rc1+ #522 [ 263.695190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [ 263.695529] RIP: 0010:dst_blackhole_mtu+0x17/0x20 [ 263.695770] Code: 00 00 00 0f 1f 44 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 10 48 83 e0 fc 8b 40 04 85 c0 75 09 48 8b 07 <8b> 80 e0 00 00 00 c3 66 90 0f 1f 44 00 00 48 89 d7 be 01 00 00 00 [ 263.696339] RSP: 0018:ffffa4a4422fbb28 EFLAGS: 00010246 [ 263.696600] RAX: 0000000000000000 RBX: ffff8ac9c3553000 RCX: 0000000000000000 [ 263.696891] RDX: 0000000000000401 RSI: 00000000fffffe01 RDI: ffffc4a43fb48900 [ 263.697178] RBP: ffffa4a4422fbb90 R08: ffffffff9622635e R09: 0000000000000002 [ 263.697469] R10: ffffffff9b69a6c0 R11: ffffa4a4422fbd0c R12: ffff8ac9d18b1a00 [ 263.697766] R13: ffff8ac9d0ce1840 R14: ffff8ac9d18b1a00 R15: ffff8ac9c3553000 [ 263.698054] FS: 00007f3704c337c0(0000) GS:ffff8acaebf40000(0000) knlGS:0000000000000000 [ 263.698470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 263.698826] CR2: 00000000000000e0 CR3: 0000000117a5c000 CR4: 00000000000006e0 [ 263.699214] Call Trace: [ 263.699505] <TASK> [ 263.699759] wg_xmit+0x411/0x450 [ 263.700059] ? bpf_skb_set_tunnel_key+0x46/0x2d0 [ 263.700382] ? dev_queue_xmit_nit+0x31/0x2b0 [ 263.700719] dev_hard_start_xmit+0xd9/0x220 [ 263.701047] __dev_queue_xmit+0x8b9/0xd30 [ 263.701344] __bpf_redirect+0x1a4/0x380 [ 263.701664] __dev_queue_xmit+0x83b/0xd30 [ 263.701961] ? packet_parse_headers+0xb4/0xf0 [ 263.702275] packet_sendmsg+0x9a8/0x16a0 [ 263.702596] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 263.702933] sock_sendmsg+0x5e/0x60 [ 263.703239] __sys_sendto+0xf0/0x160 [ 263.703549] __x64_sys_sendto+0x20/0x30 [ 263.703853] do_syscall_64+0x3b/0x90 [ 263.704162] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 263.704494] RIP: 0033:0x7f3704d50506 [ 263.704789] Code: 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 [ 263.705652] RSP: 002b:00007ffe954b0b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 263.706141] RAX: ffffffffffffffda RBX: 0000558bb259b490 RCX: 00007f3704d50506 [ 263.706544] RDX: 000000000000004a RSI: 0000558bb259b7b2 RDI: 0000000000000003 [ 263.706952] RBP: 0000000000000000 R08: 00007ffe954b0b90 R09: 0000000000000014 [ 263.707339] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe954b0b90 [ 263.707735] R13: 000000000000004a R14: 0000558bb259b7b2 R15: 0000000000000001 [ 263.708132] </TASK> [ 263.708398] Modules linked in: bridge netconsole bonding [last unloaded: bridge] [ 263.708942] CR2: 00000000000000e0 Link: https://github.com/cilium/cilium/issues/19428 Reported-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> [Jason: polyfilled for < 4.3] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I3683705bd6e968609d18c9bbcab835e2460ea438
| * | qemu: enable ACPI for SMPJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that by having CONFIG_ACPI=n, we've been failing to boot additional CPUs, and so these systems were functionally UP. The code bloat is unfortunate for build times, but I don't see an alternative. So this commit sets CONFIG_ACPI=y for x86_64 and i686 configs. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I86f16ef20ef197a1a02a1ebeaeb73b8dbcfe24c8
| * | socket: ignore v6 endpoints when ipv6 is disabledJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit fixed a memory leak on the send path in the event that IPv6 is disabled at compile time, but how did a packet even arrive there to begin with? It turns out we have previously allowed IPv6 endpoints even when IPv6 support is disabled at compile time. This is awkward and inconsistent. Instead, let's just ignore all things IPv6, the same way we do other malformed endpoints, in the case where IPv6 is disabled. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I7def019000309c6d1f9aef695f1d4f63460e59dd
| * | socket: free skb in send6 when ipv6 is disabledWang Hai2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I48a684a0e1eebab6d803dca32684c53de99373be
| * | queueing: use CFI-safe ptr_ring cleanup functionJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We make too nuanced use of ptr_ring to entirely move to the skb_array wrappers, but we at least should avoid the naughty function pointer cast when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch uses the __skb_array_destroy_skb wrapper for the cleanup, rather than directly providing kfree_skb, which is what other drivers in the same situation do too. Reported-by: PaX Team <pageexec@freemail.hu> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: Ib9ee487345484769aab6b173738c77dcac0f6f57
| * | crypto: curve25519-x86_64: use in/out register constraints more preciselyJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than passing all variables as modified, pass ones that are only read into that parameter. This helps with old gcc versions when alternatives are additionally used, and lets gcc's codegen be a little bit more efficient. This also syncs up with the latest Vale/EverCrypt output. This also forward ports 3c9f3b6 ("crypto: curve25519-x86_64: solve register constraints with reserved registers"). Cc: Aymeric Fromherz <aymeric.fromherz@inria.fr> Cc: Mathias Krause <minipli@grsecurity.net> Link: https://lore.kernel.org/wireguard/1554725710.1290070.1639240504281.JavaMail.zimbra@inria.fr/ Link: https://github.com/project-everest/hacl-star/pull/501 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: Idc46e469140c53e1bbe436894c7750e8dcfbec47
| * | compat: drop Ubuntu 14.04Jason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | It's been over a year since we announced sunsetting this. Link: https://lore.kernel.org/wireguard/CAHmME9rckipsdZYW+LA=x6wCMybdFFA+VqoogFXnR=kHYiCteg@mail.gmail.com/T Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I362f83af6dc910819c96f81a9f45849ff48fbcbb
| * | fixup! compat: redefine version constants for sublevel>=256Jason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the 4.4.256 and 4.9.256 kernels, the previous calculation for integer comparison overflowed. This commit redefines the broken constants to have more space for the sublevel. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Bruno Martins <bgcngm@gmail.com> Change-Id: I10023e96476c7f498e7f2fc8d29813ecc7c3b765
| * | wireguard: version: bumpJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Bruno Martins <bgcngm@gmail.com> Change-Id: Icde0786c87bf7bbabc733fcf2f047e1a63e47808
| * | Makefile: strip prefixed v from version.hJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We also no longer do anything dynamic with dkms.conf, and we don't rewrite any files at all, but rather pass this through as a cflag to the compiler optionally. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reported-by: Egbert Verhage <egbert@eggiecode.org> Change-Id: Ieffe702464a3caeedcf6e9552da9dc339147cad2
| * | crypto: curve25519-x86_64: solve register constraints with reserved registersMathias Krause2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The register constraints for the inline assembly in fsqr() and fsqr2() are pretty tight on what the compiler may assign to the remaining three register variables. The clobber list only allows the following to be used: RDI, RSI, RBP and R12. With RAP reserving R12 and a kernel having CONFIG_FRAME_POINTER=y, claiming RBP, there are only two registers left so the compiler rightfully complains about impossible constraints. Provide alternatives that'll allow a memory reference for 'out' to solve the allocation constraint dilemma for this configuration. Also make 'out' an input-only operand as it is only used as such. This not only allows gcc to optimize its usage further, but also works around older gcc versions, apparently failing to handle multiple alternatives correctly, as in failing to initialize the 'out' operand with its input value. Signed-off-by: Mathias Krause <minipli@grsecurity.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I7027868359c31d4e514118a2f79b4726e259ddb0
| * | compat: udp_tunnel: don't take reference to non-init namespaceJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment to sk_change_net is instructive: Kernel sockets, f.e. rtnl or icmp_socket, are a part of a namespace. They should not hold a reference to a namespace in order to allow to stop it. Sockets after sk_change_net should be released using sk_release_kernel We weren't following these rules before, and were instead using __sock_create, which means we kept a reference to the namespace, which in turn meant that interfaces were not cleaned up on namespace exit. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I03b2e58e45e3eb37c6324b23ca0d6f3fde2ebec7
| * | compat: siphash: use _unaligned version by defaultArnd Bergmann2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because the ordinary load/store instructions (ldr, ldrh, ldrb) can tolerate any misalignment of the memory address. However, load/store double and load/store multiple instructions (ldrd, ldm) may still only be used on memory addresses that are 32-bit aligned, and so we have to use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we may end up with a severe performance hit due to alignment traps that require fixups by the kernel. Testing shows that this currently happens with clang-13 but not gcc-11. In theory, any compiler version can produce this bug or other problems, as we are dealing with undefined behavior in C99 even on architectures that support this in hardware, see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363. Fortunately, the get_unaligned() accessors do the right thing: when building for ARMv6 or later, the compiler will emit unaligned accesses using the ordinary load/store instructions (but avoid the ones that require 32-bit alignment). When building for older ARM, those accessors will emit the appropriate sequence of ldrb/mov/orr instructions. And on architectures that can truly tolerate any kind of misalignment, the get_unaligned() accessors resolve to the leXX_to_cpup accessors that operate on aligned addresses. Since the compiler will in fact emit ldrd or ldm instructions when building this code for ARM v6 or later, the solution is to use the unaligned accessors unconditionally on architectures where this is known to be fast. The _aligned version of the hash function is however still needed to get the best performance on architectures that cannot do any unaligned access in hardware. This new version avoids the undefined behavior and should produce the fastest hash on all architectures we support. Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: Ifd9995cd389b5c6600b9569a3eee0bd0167f91b0
| * | ratelimiter: use kvcalloc() instead of kvzalloc()Gustavo A. R. Silva2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | Use 2-factor argument form kvcalloc() instead of kvzalloc(). Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: Ib525508a66c48d47c17c9a8b11ff40d79ae0b853
| * | receive: drop handshakes if queue lock is contendedJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we're being delivered packets from multiple CPUs so quickly that the ring lock is contended for CPU tries, then it's safe to assume that the queue is near capacity anyway, so just drop the packet rather than spinning. This helps deal with multicore DoS that can interfere with data path performance. It _still_ does not completely fix the issue, but it again chips away at it. Reported-by: Streun Fabio <fstreun@student.ethz.ch> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I6e0a372a0b26907cc4ac425ecc17bdca8e07a2aa
| * | receive: use ring buffer for incoming handshakesJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently the spinlock on incoming_handshake's skb_queue is highly contended, and a torrent of handshake or cookie packets can bring the data plane to its knees, simply by virtue of enqueueing the handshake packets to be processed asynchronously. So, we try switching this to a ring buffer to hopefully have less lock contention. This alleviates the problem somewhat, though it still isn't perfect, so future patches will have to improve this further. However, it at least doesn't completely diminish the data plane. Reported-by: Streun Fabio <fstreun@student.ethz.ch> Reported-by: Joel Wanner <joel.wanner@inf.ethz.ch> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I6e515a2092f55c8dd9cd4962300c7d01fa23cd60
| * | device: reset peer src endpoint when netns exitsJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each peer's endpoint contains a dst_cache entry that takes a reference to another netdev. When the containing namespace exits, we take down the socket and prevent future sockets from being created (by setting creating_net to NULL), which removes that potential reference on the netns. However, it doesn't release references to the netns that a netdev cached in dst_cache might be taking, so the netns still might fail to exit. Since the socket is gimped anyway, we can simply clear all the dst_caches (by way of clearing the endpoint src), which will release all references. However, the current dst_cache_reset function only releases those references lazily. But it turns out that all of our usages of wg_socket_clear_peer_endpoint_src are called from contexts that are not exactly high-speed or bottle-necked. For example, when there's connection difficulty, or when userspace is reconfiguring the interface. And in particular for this patch, when the netns is exiting. So for those cases, it makes more sense to call dst_release immediately. For that, we add a small helper function to dst_cache. This patch also adds a test to netns.sh from Hangbin Liu to ensure this doesn't regress. Test-by: Hangbin Liu <liuhangbin@gmail.com> Reported-by: Xiumei Mu <xmu@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: Ie3c2d3ffbf27c94bdfd3bc37e314d14c306c217a
| * | main: rename 'mod_init' & 'mod_exit' functions to be module-specificRandy Dunlap2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename module_init & module_exit functions that are named "mod_init" and "mod_exit" so that they are unique in both the System.map file and in initcall_debug output instead of showing up as almost anonymous "mod_init". This is helpful for debugging and in determining how long certain module_init calls take to execute. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I1ac666827bc4ad14c5018561a3b9cfe779497634
| * | netns: actually test for routing loopsJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We previously removed the restriction on looping to self, and then added a test to make sure the kernel didn't blow up during a routing loop. The kernel didn't blow up, thankfully, but on certain architectures where skb fragmentation is easier, such as ppc64, the skbs weren't actually being discarded after a few rounds through. But the test wasn't catching this. So actually test explicitly for massive increases in tx to see if we have a routing loop. Note that the actual loop problem will need to be addressed in a different commit. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I35abdbcc2b8539354ddaa15be2abe824939374ce
| * | compat: update for RHEL 8.5Peter Georg2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | RHEL 8.5 has been released. Replace all ISCENTOS8S checks with ISRHEL8. Increase RHEL_MINOR for CentOS 8 Stream detection to 6. Signed-off-by: Peter Georg <peter.georg@physik.uni-regensburg.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I0a5df2df826150569e7e22ce9a6d0649fb21a208
| * | compat: account for grsecurity backports and changesMathias Krause2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | grsecurity kernels tend to carry additional backports and changes, like commit b60b87fc2996 ("netlink: add ethernet address policy types") or the SYM_FUNC_* changes. RAP nowadays hooks the latter, therefore no diversion to RAP_ENTRY is needed any more. Instead of relying on the kernel version test, also test for the macros we're about to define to not already be defined to account for these additional changes in the grsecurity patch without breaking compatibility to the older public ones. Also test for CONFIG_PAX instead of RAP_PLUGIN for the timer API related changes as these don't depend on the RAP plugin to be enabled but just a PaX/grsecurity patch to be applied. While there is no preprocessor knob for the latter, use CONFIG_PAX as this will likely be enabled in every kernel that uses the patch. Signed-off-by: Mathias Krause <minipli@grsecurity.net> [zx2c4: small changes to include a header nearby a macro def test] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I439decf1a010630473f1679354f925f2017a9101
| * | compat: account for latest c8s backportsJason A. Donenfeld2023-11-06
| | | | | | | | | | | | | | | Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Change-Id: I6136ba1913ddd726e49405a05c70aeb8955d3234
| * | sched/walt: Add missing WALT call to `dequeue_task_fair`Alexander Grund2023-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to `dec_cfs_rq_hmp_stats` vs `walt_dec_cfs_cumulative_runnable_avg` we need to call `walt_dec_cumulative_runnable_avg` where `dec_rq_hmp_stats` is called. Corresponds to the `walt_inc_cfs_cumulative_runnable_avg` call in `enqueue_task_fair`. Based on 4e29a6c5f98f9694d5ad01a4e7899aad157f8d49 ("sched: Add missing WALT code") Fixes c0fa7577022c4169e1aaaf1bd9e04f63d285beb2 ("sched/walt: Re-add code to allow WALT to function") Change-Id: If2b291e1e509ba300d7f4b698afe73a72b273604
| * | ICE, pfk: fix to set dio_inode preciselyJaegeuk Kim2023-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using loopback device with dio, we can't rely on page flag. Bug: 141601405 Bug: 141860559 Bug: 140882488 Change-Id: I09526c25e8d5333853e777f29333f9fa8da37459 Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
| * | net: add ndo to setup/query xdp prog in adapter rxBrenden Blanco2023-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add one new netdev op for drivers implementing the BPF_PROG_TYPE_XDP filter. The single op is used for both setup/query of the xdp program, modelled after ndo_setup_tc. Change-Id: Ie46dec0b47e417e97d5fed19d7f2b143eab4ea73 Signed-off-by: Brenden Blanco <bblanco@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | netdev: introduce ndo_set_rx_headroomPaolo Abeni2023-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | This method allows the controlling device (i.e. the bridge) to specify additional headroom to be allocated for skb head on frame reception. Change-Id: Ic4938a247408a87538a11c45e3fbc2031f4ac832 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-22 09:13:17 +0000