DLPX-87970 Move Delphix annotations to linux-pkg to reduce merge conflicts #48
Conversation
This file contains hidden or 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
palash-gandhi
force-pushed
the
dlpx/pr/palash-delphix/960afe41-2f10-437d-8484-15cbf6a3e388
branch
from
a9fdbe7 to
3c3b4ff
Compare
sebroy
approved these changes
Sep 15, 2023
prakashsurya
approved these changes
Sep 15, 2023
palash-gandhi
deleted the
dlpx/pr/palash-delphix/960afe41-2f10-437d-8484-15cbf6a3e388
branch
delphix-devops-bot
pushed a commit
that referenced
this pull request
Sep 20, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 6, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 7, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 8, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 9, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 10, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 21, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Nov 1, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Nov 22, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 9, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 10, 2023
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 27, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Feb 9, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Mar 1, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Mar 21, 2024
jwk404
pushed a commit
that referenced
this pull request
Apr 14, 2024
jwk404
pushed a commit
that referenced
this pull request
Apr 15, 2024
jwk404
pushed a commit
that referenced
this pull request
Apr 15, 2024
jwk404
pushed a commit
that referenced
this pull request
Apr 15, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Apr 20, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
May 22, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
May 23, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 20, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Oct 21, 2024
palash-gandhi
added a commit
that referenced
this pull request
Oct 24, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Nov 10, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 18, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 19, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 20, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 21, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 22, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 23, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 24, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 25, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 26, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 27, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 28, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 29, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 30, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Dec 31, 2024
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 1, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 2, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 3, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 4, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 5, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Jan 7, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Feb 12, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Feb 13, 2025
delphix-devops-bot
pushed a commit
that referenced
this pull request
Mar 29, 2025
BugLink: https://bugs.launchpad.net/bugs/2089272 [ Upstream commit 60f07e2 ] We use uprobe in aarch64_be, which we found the tracee task would exit due to SIGILL when we enable the uprobe trace. We can see the replace inst from uprobe is not correct in aarch big-endian. As in Armv8-A, instruction fetches are always treated as little-endian, we should treat the UPROBE_SWBP_INSN as little-endian。 The test case is as following。 bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null & bash-4.4# cd /sys/kernel/debug/tracing/ bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events bash-4.4# echo 1 > events/uprobes/enable bash-4.4# bash-4.4# ps PID TTY TIME CMD 140 ? 00:00:01 bash 237 ? 00:00:00 ps [1]+ Illegal instruction ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null which we debug use gdb as following: bash-4.4# gdb attach 155 (gdb) disassemble send Dump of assembler code for function send: 0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined 0x0000000000400c34 <+4>: mov x29, sp 0x0000000000400c38 <+8>: str w0, [sp, #28] 0x0000000000400c3c <+12>: strb w1, [sp, #27] 0x0000000000400c40 <+16>: str xzr, [sp, #40] 0x0000000000400c44 <+20>: str xzr, [sp, #48] 0x0000000000400c48 <+24>: add x0, sp, #0x1b 0x0000000000400c4c <+28>: mov w3, #0x0 // #0 0x0000000000400c50 <+32>: mov x2, #0x1 // #1 0x0000000000400c54 <+36>: mov x1, x0 0x0000000000400c58 <+40>: ldr w0, [sp, #28] 0x0000000000400c5c <+44>: bl 0x405e10 <mq_send> 0x0000000000400c60 <+48>: str w0, [sp, #60] 0x0000000000400c64 <+52>: ldr w0, [sp, #60] 0x0000000000400c68 <+56>: ldp x29, x30, [sp], #64 0x0000000000400c6c <+60>: ret End of assembler dump. (gdb) info b No breakpoints or watchpoints. (gdb) c Continuing. Program received signal SIGILL, Illegal instruction. 0x0000000000400c30 in send () (gdb) x/10x 0x400c30 0x400c30 <send>: 0xd42000a0 0xfd030091 0xe01f00b9 0xe16f0039 0x400c40 <send+16>: 0xff1700f9 0xff1b00f9 0xe06f0091 0x03008052 0x400c50 <send+32>: 0x220080d2 0xe10300aa (gdb) disassemble 0x400c30 Dump of assembler code for function send: => 0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined 0x0000000000400c34 <+4>: mov x29, sp 0x0000000000400c38 <+8>: str w0, [sp, #28] 0x0000000000400c3c <+12>: strb w1, [sp, #27] 0x0000000000400c40 <+16>: str xzr, [sp, #40] Signed-off-by: junhua huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Manuel Diewald <[email protected]> Signed-off-by: Mehmet Basaran <[email protected]>
delphix-devops-bot
pushed a commit
that referenced
this pull request
Mar 29, 2025
commit 86e6ca5 upstream. blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Abagail ren <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Fixes: 4308a43 ("blkcg: don't offline parent blkcg first") Cc: [email protected] # v5.7+ Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> CVE-2024-56672 Signed-off-by: Noah Wager <[email protected]> Signed-off-by: Koichiro Den <[email protected]>
delphix-devops-bot
pushed a commit
that referenced
this pull request
Apr 2, 2025
blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Abagail ren <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Fixes: 4308a43 ("blkcg: don't offline parent blkcg first") Cc: [email protected] # v5.7+ Signed-off-by: Jens Axboe <[email protected]> CVE-2024-56672 (cherry picked from commit 86e6ca5) Signed-off-by: Massimiliano Pellizzer <[email protected]> Acked-by: Koichiro Den <[email protected]> Acked-by: Stewart Hore <[email protected]> Signed-off-by: Koichiro Den <[email protected]>
delphix-devops-bot
pushed a commit
that referenced
this pull request
Sep 9, 2025
… prevent wrong idmap generation BugLink: https://bugs.launchpad.net/bugs/2115252 commit 363cd2b81cfdf706bbfc9ec78db000c9b1ecc552 upstream. The PTE_MAYBE_NG macro sets the nG page table bit according to the value of "arm64_use_ng_mappings". This variable is currently placed in the .bss section. create_init_idmap() is called before the .bss section initialisation which is done in early_map_kernel(). Therefore, data/test_prot in create_init_idmap() could be set incorrectly through the PAGE_KERNEL -> PROT_DEFAULT -> PTE_MAYBE_NG macros. # llvm-objdump-21 --syms vmlinux-gcc | grep arm64_use_ng_mappings ffff800082f242a8 g O .bss 0000000000000001 arm64_use_ng_mappings The create_init_idmap() function disassembly compiled with llvm-21: // create_init_idmap() ffff80008255c058: d10103ff sub sp, sp, #0x40 ffff80008255c05c: a9017bfd stp x29, x30, [sp, #0x10] ffff80008255c060: a90257f6 stp x22, x21, [sp, #0x20] ffff80008255c064: a9034ff4 stp x20, x19, [sp, #0x30] ffff80008255c068: 910043fd add x29, sp, #0x10 ffff80008255c06c: 90003fc8 adrp x8, 0xffff800082d54000 ffff80008255c070: d280e06a mov x10, #0x703 // =1795 ffff80008255c074: 91400409 add x9, x0, #0x1, lsl #12 // =0x1000 ffff80008255c078: 394a4108 ldrb w8, [x8, #0x290] ------------- (1) ffff80008255c07c: f2e00d0a movk x10, #0x68, lsl #48 ffff80008255c080: f90007e9 str x9, [sp, #0x8] ffff80008255c084: aa0103f3 mov x19, x1 ffff80008255c088: aa0003f4 mov x20, x0 ffff80008255c08c: 14000000 b 0xffff80008255c08c <__pi_create_init_idmap+0x34> ffff80008255c090: aa082d56 orr x22, x10, x8, lsl #11 -------- (2) Note (1) is loading the arm64_use_ng_mappings value in w8 and (2) is set the text or data prot with the w8 value to set PTE_NG bit. If the .bss section isn't initialized, x8 could include a garbage value and generate an incorrect mapping. Annotate arm64_use_ng_mappings as __read_mostly so that it is placed in the .data section. Fixes: 84b04d3 ("arm64: kernel: Create initial ID map from C code") Cc: [email protected] # 6.9.x Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Yeoreum Yun <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: use __read_mostly instead of __ro_after_init] [[email protected]: slight tweaking of the code comment] Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Manuel Diewald <[email protected]> Signed-off-by: Stefan Bader <[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.
Problem
#46 and it's side ports introduced a potential for merge conflicts in the base annotations file. If upstream changes that file, we are bound to hit a merge conflict when updating our repos because the
includeline is at the end of the file. Moving it to the top result in an unwanted configuration - where upstream's annotations overrides Delphix's annotations. We want Delphix's annotations to be processed at the very end.Solution
delphix/linux-pkg#300 moves Delphix's custom annotations file into the linux-pkg repo. This change modifies the kernel repo to remove it.
Testing Done
See delphix/linux-pkg#300 for testing.