Skip to content

DLPX-83442 Disable various kernel modules which we don't use #14

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Nov 29, 2022
Merged

DLPX-83442 Disable various kernel modules which we don't use #14

merged 1 commit into from
Nov 29, 2022

Conversation

prakashsurya
Copy link

No description provided.

@prakashsurya prakashsurya force-pushed the projects/ps-overrides branch from e96c491 to c01e1d4 Compare October 19, 2022 23:50
@prakashsurya prakashsurya merged commit 4138041 into 6.0/stage Nov 29, 2022
@prakashsurya prakashsurya deleted the projects/ps-overrides branch November 29, 2022 02:33
don-brady pushed a commit to don-brady/linux-kernel-oracle that referenced this pull request Nov 29, 2022
DLPX-83442 Disable various kernel modules which we don't use (delphix#14
17cceb2 
)
delphix-devops-bot pushed a commit that referenced this pull request Dec 2, 2022
DLPX-83442 Disable various kernel modules which we don't use (#14)
82c34af
delphix-devops-bot pushed a commit that referenced this pull request Dec 15, 2022
DLPX-83442 Disable various kernel modules which we don't use (#14)
efe09a6
delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
653a48a
delphix-devops-bot pushed a commit that referenced this pull request Jan 16, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
2a53520
delphix-devops-bot pushed a commit that referenced this pull request Feb 10, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
a867b05
delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023
@smb49
arm64: Fix panic() when Spectre-v2 causes Spectre-BHB to re-allocate …
eee4b87 
…KVM vectors

BugLink: https://bugs.launchpad.net/bugs/2003896

Sami reports that linux panic()s when resuming from suspend to RAM. This
is because when CPUs are brought back online, they re-enable any
necessary mitigations.

The Spectre-v2 and Spectre-BHB mitigations interact as both need to
done by KVM when exiting a guest. Slots KVM can use as vectors are
allocated, and templates for the mitigation are patched into the vector.

This fails if a new slot needs to be allocated once the kernel has finished
booting as it is no-longer possible to modify KVM's vectors:
| root@adam:/sys/devices/system/cpu/cpu1# echo 1 > online
| Unable to handle kernel write to read-only memory at virtual add>
| Mem abort info:
|   ESR = 0x9600004e
|   Exception class = DABT (current EL), IL = 32 bits
|   SET = 0, FnV = 0
|   EA = 0, S1PTW = 0
| Data abort info:
|   ISV = 0, ISS = 0x0000004e
|   CM = 0, WnR = 1
| swapper pgtable: 4k pages, 48-bit VAs, pgdp = 000000000f07a71c
| [ffff800000b4b800] pgd=00000009ffff8803, pud=00000009ffff7803, p>
| Internal error: Oops: 9600004e [#1] PREEMPT SMP
| Modules linked in:
| Process swapper/1 (pid: 0, stack limit = 0x0000000063153c53)
| CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.252-dirty #14
| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno De>
| pstate: 000001c5 (nzcv dAIF -PAN -UAO)
| pc : __memcpy+0x48/0x180
| lr : __copy_hyp_vect_bpi+0x64/0x90

| Call trace:
|  __memcpy+0x48/0x180
|  kvm_setup_bhb_slot+0x204/0x2a8
|  spectre_bhb_enable_mitigation+0x1b8/0x1d0
|  __verify_local_cpu_caps+0x54/0xf0
|  check_local_cpu_capabilities+0xc4/0x184
|  secondary_start_kernel+0xb0/0x170
| Code: b8404423 b80044c3 3618006 f8408423 (f80084c3)
| ---[ end trace 859bcacb09555348 ]---
| Kernel panic - not syncing: Attempted to kill the idle task!
| SMP: stopping secondary CPUs
| Kernel Offset: disabled
| CPU features: 0x10,25806086
| Memory Limit: none
| ---[ end Kernel panic - not syncing: Attempted to kill the idle ]

This is only a problem on platforms where there is only one CPU that is
vulnerable to both Spectre-v2 and Spectre-BHB.

The Spectre-v2 mitigation identifies the slot it can re-use by the CPU's
'fn'. It unconditionally writes the slot number and 'template_start'
pointer. The Spectre-BHB mitigation identifies slots it can re-use by
the CPU's template_start pointer, which was previously clobbered by the
Spectre-v2 mitigation.

When there is only one CPU that is vulnerable to both issues, this causes
Spectre-v2 to try to allocate a new slot, which fails.

Change both mitigations to check whether they are changing the slot this
CPU uses before writing the percpu variables again.

This issue only exists in the stable backports for Spectre-BHB which have
to use totally different infrastructure to mainline.

Reported-by: Sami Lee <[email protected]>
Fixes: 9013fd4bc958 ("arm64: Mitigate spectre style branch history side channels")
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023
@liuhangbin @smb49
net/tunnel: wait until all sk_user_data reader finish before releasin…
104acb1 
…g the sock

BugLink: https://bugs.launchpad.net/bugs/2003914

[ Upstream commit 3cf7203 ]

There is a race condition in vxlan that when deleting a vxlan device
during receiving packets, there is a possibility that the sock is
released after getting vxlan_sock vs from sk_user_data. Then in
later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
NULL pointer dereference. e.g.

   #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757
   #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d
   #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48
   #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b
   #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb
   #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542
   #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62
      [exception RIP: vxlan_ecn_decapsulate+0x3b]
      RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246
      RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000
      RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700
      RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae
      R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700
      R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
   #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]
   #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507
   #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45
  #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807
  #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951
  #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde
  #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b
  #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139
  #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a
  #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3
  #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca
  #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3

Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh

Fix this by waiting for all sk_user_data reader to finish before
releasing the sock.

Reported-by: Jianlin Shi <[email protected]>
Suggested-by: Jakub Sitnicki <[email protected]>
Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs")
Signed-off-by: Hangbin Liu <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
2fa5361
prakashsurya pushed a commit that referenced this pull request Mar 14, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
436528a
prakashsurya pushed a commit that referenced this pull request Mar 14, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
f587b7f
delphix-devops-bot pushed a commit that referenced this pull request Mar 19, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
586e01d
delphix-devops-bot pushed a commit that referenced this pull request Mar 30, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
dcd2db9
delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
d279f44
delphix-devops-bot pushed a commit that referenced this pull request Apr 28, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
635c2cc
delphix-devops-bot pushed a commit that referenced this pull request May 31, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
e203cad
delphix-devops-bot pushed a commit that referenced this pull request Jun 3, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
d7900bf
delphix-devops-bot pushed a commit that referenced this pull request Jun 4, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
0cabeb6
delphix-devops-bot pushed a commit that referenced this pull request Jun 5, 2023
DLPX-83442 Disable various kernel modules which we don't use (#14)
ba51e51
delphix-devops-bot pushed a commit that referenced this pull request Dec 21, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
e227f45
delphix-devops-bot pushed a commit that referenced this pull request Dec 22, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
60d339e
delphix-devops-bot pushed a commit that referenced this pull request Dec 23, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
94d9e7c
delphix-devops-bot pushed a commit that referenced this pull request Dec 24, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
610aae6
delphix-devops-bot pushed a commit that referenced this pull request Dec 25, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
8f34e7a
delphix-devops-bot pushed a commit that referenced this pull request Dec 26, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
d89033c
delphix-devops-bot pushed a commit that referenced this pull request Dec 27, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
ea29d82
delphix-devops-bot pushed a commit that referenced this pull request Dec 28, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
0d3bcd5
delphix-devops-bot pushed a commit that referenced this pull request Dec 29, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
afce6d6
delphix-devops-bot pushed a commit that referenced this pull request Dec 30, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
6b9d829
delphix-devops-bot pushed a commit that referenced this pull request Dec 31, 2024
DLPX-83442 Disable various kernel modules which we don't use (#14)
c0e2b1c
delphix-devops-bot pushed a commit that referenced this pull request Jan 1, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
bd2cd6e
delphix-devops-bot pushed a commit that referenced this pull request Jan 2, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
1cb2ad3
delphix-devops-bot pushed a commit that referenced this pull request Jan 3, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
480c865
delphix-devops-bot pushed a commit that referenced this pull request Jan 4, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
e0f7872
delphix-devops-bot pushed a commit that referenced this pull request Jan 5, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
a523c8a
delphix-devops-bot pushed a commit that referenced this pull request Jan 6, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
7097417
delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
6e547c4
delphix-devops-bot pushed a commit that referenced this pull request Jan 30, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
ad68899
delphix-devops-bot pushed a commit that referenced this pull request Jan 31, 2025
DLPX-83442 Disable various kernel modules which we don't use (#14)
65357af
delphix-devops-bot pushed a commit that referenced this pull request Feb 7, 2025
@jankara @smb49
ocfs2: fix DIO failure due to insufficient transaction credits
906a263 
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]>
delphix-devops-bot pushed a commit that referenced this pull request Mar 26, 2025
@name2965 @mehmetb0
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
bfbfd7c 
[ Upstream commit 8619593634cbdf5abf43f5714df49b04e4ef09ab ]

I found the following bug in my fuzzer:

  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
  index 255 is out of range for type 'htc_endpoint [22]'
  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Workqueue: events request_firmware_work_func
  Call Trace:
   <TASK>
   dump_stack_lvl+0x180/0x1b0
   __ubsan_handle_out_of_bounds+0xd4/0x130
   htc_issue_send.constprop.0+0x20c/0x230
   ? _raw_spin_unlock_irqrestore+0x3c/0x70
   ath9k_wmi_cmd+0x41d/0x610
   ? mark_held_locks+0x9f/0xe0
   ...

Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.

Fixes: fb9987d ("ath9k_htc: Support for AR9271 chipset.")
Signed-off-by: Jeongjun Park <[email protected]>
Acked-by: Toke Høiland-Jørgensen <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Sasha Levin <[email protected]>

CVE-2024-53156
(cherry picked from commit 3fe99b9690b99606d3743c9961ebee865cfa1ab8 linux-6.11.y)
Signed-off-by: Bethany Jamison <[email protected]>
Acked-by: Koichiro Den <[email protected]>
Acked-by: Magali Lemes <[email protected]>
Signed-off-by: Koichiro Den <[email protected]>
delphix-devops-bot pushed a commit that referenced this pull request Mar 27, 2025
@mehmetb0
x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y
4696a4b 
BugLink: https://bugs.launchpad.net/bugs/2095283

commit 8d9ffb2fe65a6c4ef114e8d4f947958a12751bbe upstream.

The kdump kernel is broken on SME systems with CONFIG_IMA_KEXEC=y enabled.
Debugging traced the issue back to

  b69a2af ("x86/kexec: Carry forward IMA measurement log on kexec").

Testing was previously not conducted on SME systems with CONFIG_IMA_KEXEC
enabled, which led to the oversight, with the following incarnation:

...
  ima: No TPM chip found, activating TPM-bypass!
  Loading compiled-in module X.509 certificates
  Loaded X.509 cert 'Build time autogenerated kernel key: 18ae0bc7e79b64700122bb1d6a904b070fef2656'
  ima: Allocated hash algorithm: sha256
  Oops: general protection fault, probably for non-canonical address 0xcfacfdfe6660003e: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc2+ #14
  Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.20.0 05/03/2023
  RIP: 0010:ima_restore_measurement_list
  Call Trace:
   <TASK>
   ? show_trace_log_lvl
   ? show_trace_log_lvl
   ? ima_load_kexec_buffer
   ? __die_body.cold
   ? die_addr
   ? exc_general_protection
   ? asm_exc_general_protection
   ? ima_restore_measurement_list
   ? vprintk_emit
   ? ima_load_kexec_buffer
   ima_load_kexec_buffer
   ima_init
   ? __pfx_init_ima
   init_ima
   ? __pfx_init_ima
   do_one_initcall
   do_initcalls
   ? __pfx_kernel_init
   kernel_init_freeable
   kernel_init
   ret_from_fork
   ? __pfx_kernel_init
   ret_from_fork_asm
   </TASK>
  Modules linked in:
  ---[ end trace 0000000000000000 ]---
  ...
  Kernel panic - not syncing: Fatal exception
  Kernel Offset: disabled
  Rebooting in 10 seconds..

Adding debug printks showed that the stored addr and size of ima_kexec buffer
are not decrypted correctly like:

  ima: ima_load_kexec_buffer, buffer:0xcfacfdfe6660003e, size:0xe48066052d5df359

Three types of setup_data info

  — SETUP_EFI,
  - SETUP_IMA, and
  - SETUP_RNG_SEED

are passed to the kexec/kdump kernel. Only the ima_kexec buffer
experienced incorrect decryption. Debugging identified a bug in
early_memremap_is_setup_data(), where an incorrect range calculation
occurred due to the len variable in struct setup_data ended up only
representing the length of the data field, excluding the struct's size,
and thus leading to miscalculation.

Address a similar issue in memremap_is_setup_data() while at it.

  [ bp: Heavily massage. ]

Fixes: b3c72fc ("x86/boot: Introduce setup_indirect")
Signed-off-by: Baoquan He <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Acked-by: Tom Lendacky <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Koichiro Den <[email protected]>
delphix-devops-bot pushed a commit that referenced this pull request Mar 27, 2025
@name2965 @mehmetb0
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
984f0b1 
BugLink: https://bugs.launchpad.net/bugs/2095283

[ Upstream commit 8619593634cbdf5abf43f5714df49b04e4ef09ab ]

I found the following bug in my fuzzer:

  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
  index 255 is out of range for type 'htc_endpoint [22]'
  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Workqueue: events request_firmware_work_func
  Call Trace:
   <TASK>
   dump_stack_lvl+0x180/0x1b0
   __ubsan_handle_out_of_bounds+0xd4/0x130
   htc_issue_send.constprop.0+0x20c/0x230
   ? _raw_spin_unlock_irqrestore+0x3c/0x70
   ath9k_wmi_cmd+0x41d/0x610
   ? mark_held_locks+0x9f/0xe0
   ...

Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.

Fixes: fb9987d ("ath9k_htc: Support for AR9271 chipset.")
Signed-off-by: Jeongjun Park <[email protected]>
Acked-by: Toke Høiland-Jørgensen <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
CVE-2024-53156
Signed-off-by: Koichiro Den <[email protected]>
sebroy pushed a commit that referenced this pull request Apr 24, 2025
@pcd1193182 @sebroy
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
96505e1 
…operly started (#14)
delphix-devops-bot pushed a commit that referenced this pull request May 8, 2025
@pcd1193182
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
d18d47d 
…operly started (#14)
delphix-devops-bot pushed a commit that referenced this pull request May 17, 2025
@pcd1193182
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
e41bc3e 
…operly started (#14)
delphix-devops-bot pushed a commit that referenced this pull request May 18, 2025
@pcd1193182
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
8f6abc6 
…operly started (#14)
delphix-devops-bot pushed a commit that referenced this pull request May 19, 2025
@pcd1193182
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
ffc6247 
…operly started (#14)
delphix-devops-bot pushed a commit that referenced this pull request May 20, 2025
@pcd1193182
DLPX-83697 iscsi target login should wait until tx/rx threads have pr…
c8241da 
…operly started (#14)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sebroy sebroy sebroy approved these changes

@sdimitro sdimitro sdimitro approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@prakashsurya @sebroy @sdimitro