<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/crypto/qat, branch v5.10.257</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.257</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.257'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-08-28T14:22:35+00:00</updated>
<entry>
<title>crypto: qat - fix seq_file position update in adf_ring_next()</title>
<updated>2025-08-28T14:22:35+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2025-07-14T07:10:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5bf8f0f08aaba4a9d081aa2645dfd4582aaa744'/>
<id>urn:sha1:e5bf8f0f08aaba4a9d081aa2645dfd4582aaa744</id>
<content type='text'>
[ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ]

The `adf_ring_next()` function in the QAT debug transport interface
fails to correctly update the position index when reaching the end of
the ring elements. This triggers the following kernel warning when
reading ring files, such as
/sys/kernel/debug/qat_c6xx_&lt;D:B:D:F&gt;/transport/bank_00/ring_00:

   [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index

Ensure that the `*pos` index is incremented before returning NULL when
after the last element in the ring is found, satisfying the seq_file API
requirements and preventing the warning.

Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code")
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Ahsan Atta &lt;ahsan.atta@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak</title>
<updated>2024-06-16T11:32:34+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2024-05-08T08:39:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a718b6d2a329e069b27d9049a71be5931e71d960'/>
<id>urn:sha1:a718b6d2a329e069b27d9049a71be5931e71d960</id>
<content type='text'>
commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream.

Using completion_done to determine whether the caller has gone
away only works after a complete call.  Furthermore it's still
possible that the caller has not yet called wait_for_completion,
resulting in another potential UAF.

Fix this by making the caller use cancel_work_sync and then freeing
the memory safely.

Fixes: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery")
Cc: &lt;stable@vger.kernel.org&gt; #6.8+
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Reviewed-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - resolve race condition during AER recovery</title>
<updated>2024-04-13T10:58:05+00:00</updated>
<author>
<name>Damian Muszynski</name>
<email>damian.muszynski@intel.com</email>
</author>
<published>2024-02-09T12:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d03092550f526a79cf1ade7f0dfa74906f39eb71'/>
<id>urn:sha1:d03092550f526a79cf1ade7f0dfa74906f39eb71</id>
<content type='text'>
[ Upstream commit 7d42e097607c4d246d99225bf2b195b6167a210c ]

During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.

This results in a KFENCE bug notice.

  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
  adf_device_reset_worker+0x38/0xa0 [intel_qat]
  process_one_work+0x173/0x340

To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function.

Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Damian Muszynski &lt;damian.muszynski@intel.com&gt;
Reviewed-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - fix double free during reset</title>
<updated>2024-04-13T10:58:05+00:00</updated>
<author>
<name>Svyatoslav Pankratov</name>
<email>svyatoslav.pankratov@intel.com</email>
</author>
<published>2023-10-09T12:27:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02fa834fb427e4662331acdfe06fa2d97e1dc35c'/>
<id>urn:sha1:02fa834fb427e4662331acdfe06fa2d97e1dc35c</id>
<content type='text'>
[ Upstream commit 01aed663e6c421aeafc9c330bda630976b50a764 ]

There is no need to free the reset_data structure if the recovery is
unsuccessful and the reset is synchronous. The function
adf_dev_aer_schedule_reset() handles the cleanup properly. Only
asynchronous resets require such structure to be freed inside the reset
worker.

Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
Signed-off-by: Svyatoslav Pankratov &lt;svyatoslav.pankratov@intel.com&gt;
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - increase size of buffers</title>
<updated>2023-11-20T10:06:50+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2023-09-22T09:03:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63e8e2ee58156935490c293ef4363ded088866b8'/>
<id>urn:sha1:63e8e2ee58156935490c293ef4363ded088866b8</id>
<content type='text'>
[ Upstream commit 4e4e2ed22d505c5bacf65c6a39bfb6d120d24785 ]

Increase the size of the buffers used for composing the names used for
the transport debugfs entries and the vector name to avoid a potential
truncation.

This resolves the following errors when compiling the driver with W=1
and KCFLAGS=-Werror on GCC 12.3.1:

    drivers/crypto/intel/qat/qat_common/adf_transport_debug.c: In function ‘adf_ring_debugfs_add’:
    drivers/crypto/intel/qat/qat_common/adf_transport_debug.c:100:60: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
    drivers/crypto/intel/qat/qat_common/adf_isr.c: In function ‘adf_isr_resource_alloc’:
    drivers/crypto/intel/qat/qat_common/adf_isr.c:197:47: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 5 [-Werror=format-truncation=]

Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code")
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Damian Muszynski &lt;damian.muszynski@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - mask device capabilities with soft straps</title>
<updated>2023-11-20T10:06:50+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2020-10-12T20:38:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a921d6b795a00c0b7fc5dffada4b9afd54ed1ca0'/>
<id>urn:sha1:a921d6b795a00c0b7fc5dffada4b9afd54ed1ca0</id>
<content type='text'>
[ Upstream commit 7b07ed5042c5d21467af5aa055f2b49b2e661a83 ]

Enable acceleration engines (AEs) and accelerators based on soft straps
and fuses. When looping with a number of AEs or accelerators, ignore the
ones that are disabled.

This patch is based on earlier work done by Conor McLoughlin.

Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Fiona Trahe &lt;fiona.trahe@intel.com&gt;
Reviewed-by: Wojciech Ziemba &lt;wojciech.ziemba@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: 4e4e2ed22d50 ("crypto: qat - increase size of buffers")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - fix DMA transfer direction</title>
<updated>2022-10-26T11:25:42+00:00</updated>
<author>
<name>Damian Muszynski</name>
<email>damian.muszynski@intel.com</email>
</author>
<published>2022-09-09T10:49:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=426d5bc089e7731e36b514d1beca19e777a2d653'/>
<id>urn:sha1:426d5bc089e7731e36b514d1beca19e777a2d653</id>
<content type='text'>
[ Upstream commit cf5bb835b7c8a5fee7f26455099cca7feb57f5e9 ]

When CONFIG_DMA_API_DEBUG is selected, while running the crypto self
test on the QAT crypto algorithms, the function add_dma_entry() reports
a warning similar to the one below, saying that overlapping mappings
are not supported. This occurs in tests where the input and the output
scatter list point to the same buffers (i.e. two different scatter lists
which point to the same chunks of memory).

The logic that implements the mapping uses the flag DMA_BIDIRECTIONAL
for both the input and the output scatter lists which leads to
overlapped write mappings. These are not supported by the DMA layer.

Fix by specifying the correct DMA transfer directions when mapping
buffers. For in-place operations where the input scatter list
matches the output scatter list, buffers are mapped once with
DMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flag
DMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE.
Overlapping a read mapping with a write mapping is a valid case in
dma-coherent devices like QAT.
The function that frees and unmaps the buffers, qat_alg_free_bufl()
has been changed accordingly to the changes to the mapping function.

   DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported
   WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270
   ...
   Call Trace:
   dma_map_page_attrs+0x82/0x2d0
   ? preempt_count_add+0x6a/0xa0
   qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat]
   qat_alg_aead_dec+0x71/0x250 [intel_qat]
   crypto_aead_decrypt+0x3d/0x70
   test_aead_vec_cfg+0x649/0x810
   ? number+0x310/0x3a0
   ? vsnprintf+0x2a3/0x550
   ? scnprintf+0x42/0x70
   ? valid_sg_divisions.constprop.0+0x86/0xa0
   ? test_aead_vec+0xdf/0x120
   test_aead_vec+0xdf/0x120
   alg_test_aead+0x185/0x400
   alg_test+0x3d8/0x500
   ? crypto_acomp_scomp_free_ctx+0x30/0x30
   ? __schedule+0x32a/0x12a0
   ? ttwu_queue_wakelist+0xbf/0x110
   ? _raw_spin_unlock_irqrestore+0x23/0x40
   ? try_to_wake_up+0x83/0x570
   ? _raw_spin_unlock_irqrestore+0x23/0x40
   ? __set_cpus_allowed_ptr_locked+0xea/0x1b0
   ? crypto_acomp_scomp_free_ctx+0x30/0x30
   cryptomgr_test+0x27/0x50
   kthread+0xe6/0x110
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork+0x1f/0x30

Fixes: d370cec ("crypto: qat - Intel(R) QAT crypto interface")
Link: https://lore.kernel.org/linux-crypto/20220223080400.139367-1-gilad@benyossef.com/
Signed-off-by: Damian Muszynski &lt;damian.muszynski@intel.com&gt;
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - use pre-allocated buffers in datapath</title>
<updated>2022-10-26T11:25:42+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2022-05-09T13:34:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a43babc059a7a992bd9d3bb14c4caf053ee7f7a5'/>
<id>urn:sha1:a43babc059a7a992bd9d3bb14c4caf053ee7f7a5</id>
<content type='text'>
[ Upstream commit e0831e7af4e03f2715de102e18e9179ec0a81562 ]

In order to do DMAs, the QAT device requires that the scatterlist
structures are mapped and translated into a format that the firmware can
understand. This is defined as the composition of a scatter gather list
(SGL) descriptor header, the struct qat_alg_buf_list, plus a variable
number of flat buffer descriptors, the struct qat_alg_buf.

The allocation and mapping of these data structures is done each time a
request is received from the skcipher and aead APIs.
In an OOM situation, this behaviour might lead to a dead-lock if an
allocation fails.

Based on the conversation in [1], increase the size of the aead and
skcipher request contexts to include an SGL descriptor that can handle
a maximum of 4 flat buffers.
If requests exceed 4 entries buffers, memory is allocated dynamically.

[1] https://lore.kernel.org/linux-crypto/20200722072932.GA27544@gondor.apana.org.au/

Cc: stable@vger.kernel.org
Fixes: d370cec32194 ("crypto: qat - Intel(R) QAT crypto interface")
Reported-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Marco Chiappero &lt;marco.chiappero@intel.com&gt;
Reviewed-by: Wojciech Ziemba &lt;wojciech.ziemba@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: cf5bb835b7c8 ("crypto: qat - fix DMA transfer direction")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - fix use of 'dma_map_single'</title>
<updated>2022-10-26T11:25:42+00:00</updated>
<author>
<name>Hui Tang</name>
<email>tanghui20@huawei.com</email>
</author>
<published>2021-03-05T06:35:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a91af50850270554a4ff032a12eaa4c2fed0dd44'/>
<id>urn:sha1:a91af50850270554a4ff032a12eaa4c2fed0dd44</id>
<content type='text'>
[ Upstream commit 7cc05071f930a631040fea16a41f9d78771edc49 ]

DMA_TO_DEVICE synchronisation must be done after the last modification
of the memory region by the software and before it is handed off to
the device.

Signed-off-by: Hui Tang &lt;tanghui20@huawei.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: cf5bb835b7c8 ("crypto: qat - fix DMA transfer direction")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - disable registration of algorithms</title>
<updated>2022-03-28T07:57:10+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2022-03-04T17:54:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c971e6a1c8fa0816a0a5401b3a9ad137fe112eee'/>
<id>urn:sha1:c971e6a1c8fa0816a0a5401b3a9ad137fe112eee</id>
<content type='text'>
commit 8893d27ffcaf6ec6267038a177cb87bcde4dd3de upstream.

The implementations of aead and skcipher in the QAT driver do not
support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
If the HW queue is full, the driver returns -EBUSY but does not enqueue
the request.
This can result in applications like dm-crypt waiting indefinitely for a
completion of a request that was never submitted to the hardware.

To avoid this problem, disable the registration of all crypto algorithms
in the QAT driver by setting the number of crypto instances to 0 at
configuration time.

Cc: stable@vger.kernel.org
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
