DLPX-84907 CVE-2022-3628 #21

prakashsurya · 2023-02-28T22:09:37Z

This removes unnecessary modules from our kernel.

PR URL: https://www.github.com/delphix/linux-kernel-generic/pull/21

prakashsurya · 2023-03-01T16:49:57Z

Before

delphix@ps-stage:~/before$ aws s3 sync --only-show-errors s3://snapshot-de-images/builds/jenkins-ops/linux-pkg/6.0/stage/build-package/linux-kernel-generic/post-push/23 .
delphix@ps-stage:~/before$ ls *.deb | xargs -n1 dpkg -c | grep -e brcmutil.ko -e brcmsmac.ko -e brcmfmac.ko
-rw-r--r-- root/root    439769 2023-02-16 01:20 ./lib/modules/5.4.0-139-dx2023021600-8ebedd708-generic/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
-rw-r--r-- root/root    789833 2023-02-16 01:20 ./lib/modules/5.4.0-139-dx2023021600-8ebedd708-generic/kernel/drivers/net/wireless/broadcom/brcm80211/brcmsmac/brcmsmac.ko
-rw-r--r-- root/root     17817 2023-02-16 01:20 ./lib/modules/5.4.0-139-dx2023021600-8ebedd708-generic/kernel/drivers/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko

After

delphix@ps-stage:~/after$ aws s3 sync --only-show-errors s3://dev-de-images/builds/jenkins-selfservice/linux-pkg/6.0/stage/build-package/linux-kernel-generic/pre-push/38 .
delphix@ps-stage:~/after$ ls *.deb | xargs -n1 dpkg -c | grep -e brcmutil.ko -e brcmsmac.ko -e brcmfmac.ko
delphix@ps-stage:~/after$

BugLink: https://bugs.launchpad.net/bugs/2003914 [ Upstream commit 9de255c ] Commit b743512 ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") started calling disable_irq() without holding the spinlock because it can sleep. However, that fix introduced another bug: if interrupt is already disabled and a new disable request comes in, then the spinlock is not unlocked: root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002 [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc] [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21 [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 14.855664] Call Trace: [ 14.855861] <TASK> [ 14.856025] dump_stack_lvl+0x4d/0x67 [ 14.856325] dump_stack+0x14/0x1a [ 14.856583] __schedule_bug.cold+0x4b/0x5c [ 14.856915] __schedule+0xe81/0x13d0 [ 14.857199] ? idr_find+0x13/0x20 [ 14.857456] ? get_work_pool+0x2d/0x50 [ 14.857756] ? __flush_work+0x233/0x280 [ 14.858068] ? __schedule+0xa95/0x13d0 [ 14.858307] ? idr_find+0x13/0x20 [ 14.858519] ? get_work_pool+0x2d/0x50 [ 14.858798] schedule+0x6c/0x100 [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110 [ 14.859335] ? tty_write_room+0x1f/0x30 [ 14.859598] ? n_tty_poll+0x1ec/0x220 [ 14.859830] ? tty_ldisc_deref+0x1a/0x20 [ 14.860090] schedule_hrtimeout_range+0x17/0x20 [ 14.860373] do_select+0x596/0x840 [ 14.860627] ? __kernel_text_address+0x16/0x50 [ 14.860954] ? poll_freewait+0xb0/0xb0 [ 14.861235] ? poll_freewait+0xb0/0xb0 [ 14.861517] ? rpm_resume+0x49d/0x780 [ 14.861798] ? common_interrupt+0x59/0xa0 [ 14.862127] ? asm_common_interrupt+0x2b/0x40 [ 14.862511] ? __uart_start.isra.0+0x61/0x70 [ 14.862902] ? __check_object_size+0x61/0x280 [ 14.863255] core_sys_select+0x1c6/0x400 [ 14.863575] ? vfs_write+0x1c9/0x3d0 [ 14.863853] ? vfs_write+0x1c9/0x3d0 [ 14.864121] ? _copy_from_user+0x45/0x70 [ 14.864526] do_pselect.constprop.0+0xb3/0xf0 [ 14.864893] ? do_syscall_64+0x6d/0x90 [ 14.865228] ? do_syscall_64+0x6d/0x90 [ 14.865556] __x64_sys_pselect6+0x76/0xa0 [ 14.865906] do_syscall_64+0x60/0x90 [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50 [ 14.866640] ? do_syscall_64+0x6d/0x90 [ 14.866972] ? do_syscall_64+0x6d/0x90 [ 14.867286] ? do_syscall_64+0x6d/0x90 [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] stripped [ 14.872959] </TASK> ('myfpga' is a simple 'uio_dmem_genirq' driver I wrote to test this) The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and it is used in a similar manner to the "uio_pdrv_genirq" driver with respect to interrupt configuration and handling. At the time "uio_dmem_genirq" was introduced, both had the same implementation of the 'uio_info' handlers irqcontrol() and handler(). Then commit 34cb275 ("UIO: Fix concurrency issue"), which was only applied to "uio_pdrv_genirq", ended up making them a little different. That commit, among other things, changed disable_irq() to disable_irq_nosync() in the implementation of irqcontrol(). The motivation there was to avoid a deadlock between irqcontrol() and handler(), since it added a spinlock in the irq handler, and disable_irq() waits for the completion of the irq handler. By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also avoid the sleeping-while-atomic bug that commit b743512 ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") was trying to fix. Thus, this fixes the missing unlock in irqcontrol() by importing the implementation of irqcontrol() handler from the "uio_pdrv_genirq" driver. In the end, it reverts commit b743512 ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") and change disable_irq() to disable_irq_nosync(). It is worth noting that this still does not address the concurrency issue fixed by commit 34cb275 ("UIO: Fix concurrency issue"). It will be addressed separately in the next commits. Split out from commit 34cb275 ("UIO: Fix concurrency issue"). Fixes: b743512 ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") Signed-off-by: Rafael Mendonca <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Stefan Bader <[email protected]>

…elphix#21)

BugLink: https://bugs.launchpad.net/bugs/2023230 [ Upstream commit 4e264be ] When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). Fixes: 9745780 ("iavf: Add waiting so the port is initialized in remove") Fixes: a841733 ("iavf: Fix race condition between iavf_shutdown and iavf_remove") Reported-by: Marius Cornea <[email protected]> Signed-off-by: Stefan Assmann <[email protected]> Reviewed-by: Michal Kubiak <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Luke Nowakowski-Krijger <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2073765 commit be346c1a6eeb49d8fda827d2a9522124c2f72f36 upstream. The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: c15471f ("ocfs2: fix sparse file & data ordering issue in direct io") Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Reviewed-by: Heming Zhao <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Portia Stephens <[email protected]> Signed-off-by: Roxana Nicolescu <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2076435 commit be346c1a6eeb49d8fda827d2a9522124c2f72f36 upstream. The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: c15471f ("ocfs2: fix sparse file & data ordering issue in direct io") Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Reviewed-by: Heming Zhao <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Portia Stephens <[email protected]> Signed-off-by: Roxana Nicolescu <[email protected]>

DLPX-84907 CVE-2022-3628

9683dc9

PR URL: https://www.github.com/delphix/linux-kernel-generic/pull/21

prakashsurya force-pushed the dlpx/pr/prakashsurya/5cc4b7a4-9461-4594-a3f2-5b8fe7227126 branch from 5f78f0a to 9683dc9 Compare February 28, 2023 22:09

prakashsurya marked this pull request as ready for review March 1, 2023 16:50

prakashsurya enabled auto-merge (squash) March 1, 2023 17:03

sdimitro approved these changes Mar 1, 2023

View reviewed changes

don-brady approved these changes Mar 1, 2023

View reviewed changes

prakashsurya merged commit d074c84 into 6.0/stage Mar 1, 2023

prakashsurya deleted the dlpx/pr/prakashsurya/5cc4b7a4-9461-4594-a3f2-5b8fe7227126 branch March 1, 2023 17:08

delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023

DLPX-84907 CVE-2022-3628 (#21)

6f818de

sdimitro pushed a commit to sdimitro/linux-kernel-generic that referenced this pull request Mar 6, 2023

target: login should wait until tx/rx threads have properly started. (d…

3917c9d

…elphix#21)

prakashsurya pushed a commit that referenced this pull request Mar 14, 2023

DLPX-84907 CVE-2022-3628 (#21)

86dc922

prakashsurya pushed a commit that referenced this pull request Mar 14, 2023

DLPX-84907 CVE-2022-3628 (#21)

1858e00

delphix-devops-bot pushed a commit that referenced this pull request Mar 30, 2023

DLPX-84907 CVE-2022-3628 (#21)

e1585f5

delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023

DLPX-84907 CVE-2022-3628 (#21)

35373c7

delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023

DLPX-84907 CVE-2022-3628 (#21)

cb5d955

delphix-devops-bot pushed a commit that referenced this pull request Apr 28, 2023

DLPX-84907 CVE-2022-3628 (#21)

b4737ab

delphix-devops-bot pushed a commit that referenced this pull request May 26, 2023

DLPX-84907 CVE-2022-3628 (#21)

c88a36f

delphix-devops-bot pushed a commit that referenced this pull request Jun 3, 2023

DLPX-84907 CVE-2022-3628 (#21)

5cf719c

delphix-devops-bot pushed a commit that referenced this pull request Jun 4, 2023

DLPX-84907 CVE-2022-3628 (#21)

bf1d65f

delphix-devops-bot pushed a commit that referenced this pull request Jun 5, 2023

DLPX-84907 CVE-2022-3628 (#21)

e8ed748

prakashsurya pushed a commit that referenced this pull request Aug 8, 2023

DLPX-84907 CVE-2022-3628 (#21)

5ca21a5

delphix-devops-bot pushed a commit that referenced this pull request Aug 24, 2023

DLPX-84907 CVE-2022-3628 (#21)

dfaf36d

delphix-devops-bot pushed a commit that referenced this pull request Aug 25, 2023

DLPX-84907 CVE-2022-3628 (#21)

c39e7ee

delphix-devops-bot pushed a commit that referenced this pull request Aug 26, 2023

DLPX-84907 CVE-2022-3628 (#21)

61ecc74

delphix-devops-bot pushed a commit that referenced this pull request Aug 27, 2023

DLPX-84907 CVE-2022-3628 (#21)

7df55f3

delphix-devops-bot pushed a commit that referenced this pull request Aug 28, 2023

DLPX-84907 CVE-2022-3628 (#21)

dc16185

delphix-devops-bot pushed a commit that referenced this pull request Aug 30, 2023

DLPX-84907 CVE-2022-3628 (#21)

641bd5b

delphix-devops-bot pushed a commit that referenced this pull request Aug 22, 2024

DLPX-84907 CVE-2022-3628 (#21)

66602c0

delphix-devops-bot pushed a commit that referenced this pull request Aug 23, 2024

DLPX-84907 CVE-2022-3628 (#21)

ea5ec0c

prakashsurya pushed a commit that referenced this pull request Sep 23, 2024

DLPX-84907 CVE-2022-3628 (#21)

77c0bcf

palash-gandhi pushed a commit that referenced this pull request Oct 16, 2024

DLPX-84907 CVE-2022-3628 (#21)

2b88ee5

palash-gandhi mentioned this pull request Oct 16, 2024

DLPX-92453 Cherry-pick Delphix commits of linux-kernel-generic for LTS upgrade #44

Merged

delphix-devops-bot pushed a commit that referenced this pull request Oct 20, 2024

DLPX-84907 CVE-2022-3628 (#21)

2c759c1

delphix-devops-bot pushed a commit that referenced this pull request Nov 10, 2024

DLPX-84907 CVE-2022-3628 (#21)

b527a01

delphix-devops-bot pushed a commit that referenced this pull request Nov 20, 2024

DLPX-84907 CVE-2022-3628 (#21)

9e39b74

delphix-devops-bot pushed a commit that referenced this pull request Dec 20, 2024

DLPX-84907 CVE-2022-3628 (#21)

5f2bb43

delphix-devops-bot pushed a commit that referenced this pull request Dec 21, 2024

DLPX-84907 CVE-2022-3628 (#21)

4339dd7

delphix-devops-bot pushed a commit that referenced this pull request Dec 22, 2024

DLPX-84907 CVE-2022-3628 (#21)

a030a23

delphix-devops-bot pushed a commit that referenced this pull request Dec 23, 2024

DLPX-84907 CVE-2022-3628 (#21)

4e527cb

delphix-devops-bot pushed a commit that referenced this pull request Dec 24, 2024

DLPX-84907 CVE-2022-3628 (#21)

3fa2dbd

delphix-devops-bot pushed a commit that referenced this pull request Dec 25, 2024

DLPX-84907 CVE-2022-3628 (#21)

5443fc2

delphix-devops-bot pushed a commit that referenced this pull request Dec 27, 2024

DLPX-84907 CVE-2022-3628 (#21)

65c1f82

delphix-devops-bot pushed a commit that referenced this pull request Dec 28, 2024

DLPX-84907 CVE-2022-3628 (#21)

30728d0

delphix-devops-bot pushed a commit that referenced this pull request Dec 29, 2024

DLPX-84907 CVE-2022-3628 (#21)

56b69c0

delphix-devops-bot pushed a commit that referenced this pull request Dec 30, 2024

DLPX-84907 CVE-2022-3628 (#21)

89a58d9

delphix-devops-bot pushed a commit that referenced this pull request Dec 31, 2024

DLPX-84907 CVE-2022-3628 (#21)

7d40b83

delphix-devops-bot pushed a commit that referenced this pull request Jan 1, 2025

DLPX-84907 CVE-2022-3628 (#21)

cf26b9f

delphix-devops-bot pushed a commit that referenced this pull request Jan 2, 2025

DLPX-84907 CVE-2022-3628 (#21)

e9f9904

delphix-devops-bot pushed a commit that referenced this pull request Jan 3, 2025

DLPX-84907 CVE-2022-3628 (#21)

78002f1

delphix-devops-bot pushed a commit that referenced this pull request Jan 4, 2025

DLPX-84907 CVE-2022-3628 (#21)

3a36867

delphix-devops-bot pushed a commit that referenced this pull request Jan 5, 2025

DLPX-84907 CVE-2022-3628 (#21)

c7a082d

delphix-devops-bot pushed a commit that referenced this pull request Jan 6, 2025

DLPX-84907 CVE-2022-3628 (#21)

1742d11

delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2025

DLPX-84907 CVE-2022-3628 (#21)

707e1ba

delphix-devops-bot pushed a commit that referenced this pull request Jan 30, 2025

DLPX-84907 CVE-2022-3628 (#21)

39d4ed4

delphix-devops-bot pushed a commit that referenced this pull request Jan 31, 2025

DLPX-84907 CVE-2022-3628 (#21)

f50b72c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DLPX-84907 CVE-2022-3628 #21

DLPX-84907 CVE-2022-3628 #21

prakashsurya commented Feb 28, 2023 •

edited

Loading

prakashsurya commented Mar 1, 2023 •

edited

Loading

DLPX-84907 CVE-2022-3628 #21

DLPX-84907 CVE-2022-3628 #21

Conversation

prakashsurya commented Feb 28, 2023 • edited Loading

prakashsurya commented Mar 1, 2023 • edited Loading

Before

After

prakashsurya commented Feb 28, 2023 •

edited

Loading

prakashsurya commented Mar 1, 2023 •

edited

Loading