The remote Fedora 39 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2024-d16d94b00d advisory.

  - In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion     failure and crash because a subvolume can be read out too soon after its root item is inserted upon     subvolume creation. (CVE-2024-23850)

  - copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than     INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to     ctl_ioctl. (CVE-2024-23851)

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2023-52437)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work     scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit     as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling     complete(). This seems more logical in the first place, as it's the inverse order of what the submitting     thread will do. (CVE-2024-26585)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with     partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so     the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when     we try to read from the partially-read skb. (CVE-2024-26582)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto     requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API,     crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example,     when the cryptd queue for AESNI is full (easy to trigger with an artificially low     cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case,     the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just     ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new     tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the     error handling paths. The handling is identical. (CVE-2024-26584)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and     socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto     handler calls complete() so any code past that point risks touching already freed data. Try to avoid the     locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend     solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we     are now tightly controlling when completion fires. (CVE-2024-26583)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call     transactions According to the Intel datasheets, software must reset the block buffer index twice for block     process call transactions: once before writing the outgoing data to the buffer, and once again before     reading the incoming data from the buffer. The driver is currently missing the second reset, causing the     wrong portion of the block buffer to be read. (CVE-2024-26593)

  - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for     info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken     from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a     sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in     fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer     required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area     which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the     still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead,     fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak     subject / changelog ] (CVE-2024-26603)

  - In the Linux kernel, the following vulnerability has been resolved: Revert kobject: Remove redundant     checks for whether ktype is NULL This reverts commit 1b28cb81dab7c1eedc6034206f4e8d644046ad31. It is     reported to cause problems, so revert it for now until the root cause can be found. (CVE-2024-26604)

  - In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-     work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption.
    Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make     use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads     are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an     event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as     the thread has pending work. (CVE-2024-26606)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2024-71f0f16533 advisory.

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2023-52437)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work     scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit     as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling     complete(). This seems more logical in the first place, as it's the inverse order of what the submitting     thread will do. (CVE-2024-26585)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with     partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so     the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when     we try to read from the partially-read skb. (CVE-2024-26582)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto     requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API,     crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example,     when the cryptd queue for AESNI is full (easy to trigger with an artificially low     cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case,     the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just     ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new     tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the     error handling paths. The handling is identical. (CVE-2024-26584)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and     socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto     handler calls complete() so any code past that point risks touching already freed data. Try to avoid the     locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend     solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we     are now tightly controlling when completion fires. (CVE-2024-26583)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call     transactions According to the Intel datasheets, software must reset the block buffer index twice for block     process call transactions: once before writing the outgoing data to the buffer, and once again before     reading the incoming data from the buffer. The driver is currently missing the second reset, causing the     wrong portion of the block buffer to be read. (CVE-2024-26593)

  - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for     info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken     from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a     sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in     fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer     required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area     which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the     still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead,     fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak     subject / changelog ] (CVE-2024-26603)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

リモートの Fedora 39 ホストには、FEDORA-2024-d16d94b00d のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 6.7.1 までの、Linux カーネルの fs/btrfs/disk-io.c の btrfs_get_root_ref では、アサーション失敗およびクラッシュが発生する可能性があります。これは、サブボリューム作成時に、サブボリュームのルート項目が挿入された後すぐサブボリュームが読み取られる可能性があるためです。(CVE-2024-23850)

  - 6.7.1 までの Linux カーネルの drivers/md/dm-ioctl.c の copy_params は、param_kernel->data_size チェックがないため、INT_MAX バイトを超える割り当てを試みてクラッシュする可能性があります。これは、ctl_ioctl に関連しています。(CVE-2024-23851)

  - 拒否された理由: この CVE ID は、CVE Numbering Authority により拒否または撤回されました。
    (CVE-2023-52437)

  - Linux カーネルでは、次の脆弱性が解決されています。tls: tx 作業スケジュールとソケットクローズの間の競合を修正します。以前のコミットと同様、送信中のスレッド (recvmsg/sendmsg) が、非同期暗号ハンドラーが complete() を呼び出すとすぐに終了する可能性があります。complete() を呼び出す前に作業のスケジュールを並べ替えます。これは、送信スレッドが行うことの逆の順序であるため、第一に、より論理的に思えます。(CVE-2024-26585)

  - Linux カーネルでは、次の脆弱性が解決されています。net: tls: 部分的な読み取りと非同期復号化での use-after-free を修正します。tls_decrypt_sg は、clear_skb からのページを参照しないため、tls_decrypt_done の put_page() がそれらを解放し、部分的に読み取られた skb から読み取ろうとすると、process_rx_list で use-after-free が発生します。(CVE-2024-26582)

  - Linux カーネルでは、次の脆弱性が解決されています。net: tls: 暗号リクエストのバックログを処理します。暗号 API へのリクエストに CRYPTO_TFM_REQ_MAY_BACKLOG フラグを設定しているため、crypto_aead_{encrypt、decrypt} が有効な状況でも -EINPROGRESS の代わりに -EBUSY を返す可能性があります。たとえば、AESNI の cryptd キューがいっぱいである場合 (人為的に低い cryptd.cryptd_max_cpu_qlen でトリガーしやすい)、リクエストはバックログのキューに入れられますが処理は継続されます。その場合、非同期コールバックも 2 回呼び出されます。最初は無視できる err == -EINPROGRESS で、次に err == 0 で呼び出されます。Sabrina の元のパッチと比較して、このバージョンでは新しい tls_*crypt_async_wait() ヘルパーを使用して、EBUSY を EINPROGRESS に変換しすべてのエラー処理パスを変更する必要を回避します。処理は同じです。(CVE-2024-26584)

  - Linux カーネルでは、次の脆弱性が解決されています。tls: 非同期通知とソケットクローズの間の競合を修正します。送信中のスレッド (recvmsg/sendmsg と呼ばれていた) が、非同期暗号ハンドラーが complete() を呼び出すとすぐに終了する可能性があり、その後のどのコードでもすでに解放されたデータにアクセスする危険があります。ロックと余分なフラグをすべて一緒に回避するようにしてください。メインスレッドに追加の参照を保持させて、同期をアトミック参照カウンターのみに依存させることができます。完了の再初期化を待つ必要はありません。完了が起動するタイミングが厳密に制御されるようになりました。(CVE-2024-26583)

  - Linux カーネルでは、以下の脆弱性が解決されています。i2c: i801: ブロックプロセス呼び出しトランザクションを修正してます。Intel データシートによると、ソフトウェアはブロックプロセス呼び出しトランザクションのブロックバッファインデックスを 2 回リセットしなければなりません。バッファに送信データを書き込む前とバッファから着信データを読み取る前です。ドライバーには現在 2 番目のリセットがないため、ブロックバッファの誤った部分が読み取られます。(CVE-2024-26593)

  - Linux カーネルで、次の脆弱性が解決されています。x86/fpu: 情報についてユーザー空間に依存することを止め、xsave バッファで障害を発生させないようにします。この変更前は、ユーザー空間バッファの予想されるサイズは fx_sw->xstate_size から取得されていました。fx_sw->xstate_size はユーザー空間から変更できるため、次のような状況で sigreturn フレームの構築が可能でした。* fx_sw->xstate_size が、fx_sw->xfeatures の有効なビットによって必要とされるサイズよりも小さい。* ユーザー空間が sigrame fpu バッファの一部のマッピングを解除し、xrstor が必要とするバッファの一部にアクセスできない。この場合、xrstor はマッピングされていない領域を復元してアクセスしようとするため、障害が発生します。しかし、buf + fx_sw->xstate_size がまだマップされている領域内にあり、戻って xrstor を再試行するため、fault_in_readable は成功します。これは無限ループになります。代わりに、XRSTOR が操作できる最大サイズに障害があります (fpstate->user_size から取得)。[dhansen: 件名の調整/変更ログ] (CVE-2024-26603)

  - Linux カーネルでは、次の脆弱性が解決されています。kobject を戻す: ktype が NULL であるかどうかを確認する冗長なチェックを削除します。これにより、コミット 1b28cb81dab7c1eedc6034206f4e8d644046ad31 を戻します。問題を引き起こすことが報告されているため、根本原因が見つかるまで当面の間、元に戻します。(CVE-2024-26604)

  - Linux カーネルにおいて、以下の脆弱性が解決されています。バインダー: 自己作業のスレッドに epoll シグナルを送ります。(e)poll モードでは、多くの場合、スレッドは、データを消費する準備ができている時期を判断するために I/O イベントに依存しています。
    バインダー内で、スレッドが読み取りバッファなしで BINDER_WRITE_READ を介してコマンドを開始し、その後で応答を消費するために epoll_wait() または類似のものを使用する可能性があります。その場合、epoll スレッドが自身の作業をキューに入れるときは、wakeup でシグナルを送ることが重要です。そうしないと、作業を処理しないまま、イベントが発生するのを無期限に待機するリスクがあります。さらに悪いことに、スレッドに保留中の作業があるため、後続のコマンドも wakeup をトリガーしません。(CVE-2024-26606)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートの Fedora 38 ホストには、FEDORA-2024-71f0f16533 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 拒否された理由: この CVE ID は、CVE Numbering Authority により拒否または撤回されました。
    (CVE-2023-52437)

  - Linux カーネルでは、次の脆弱性が解決されています。tls: tx 作業スケジュールとソケットクローズの間の競合を修正します。以前のコミットと同様、送信中のスレッド (recvmsg/sendmsg) が、非同期暗号ハンドラーが complete() を呼び出すとすぐに終了する可能性があります。complete() を呼び出す前に作業のスケジュールを並べ替えます。これは、送信スレッドが行うことの逆の順序であるため、第一に、より論理的に思えます。(CVE-2024-26585)

  - Linux カーネルでは、次の脆弱性が解決されています。net: tls: 部分的な読み取りと非同期復号化での use-after-free を修正します。tls_decrypt_sg は、clear_skb からのページを参照しないため、tls_decrypt_done の put_page() がそれらを解放し、部分的に読み取られた skb から読み取ろうとすると、process_rx_list で use-after-free が発生します。(CVE-2024-26582)

  - Linux カーネルでは、次の脆弱性が解決されています。net: tls: 暗号リクエストのバックログを処理します。暗号 API へのリクエストに CRYPTO_TFM_REQ_MAY_BACKLOG フラグを設定しているため、crypto_aead_{encrypt、decrypt} が有効な状況でも -EINPROGRESS の代わりに -EBUSY を返す可能性があります。たとえば、AESNI の cryptd キューがいっぱいである場合 (人為的に低い cryptd.cryptd_max_cpu_qlen でトリガーしやすい)、リクエストはバックログのキューに入れられますが処理は継続されます。その場合、非同期コールバックも 2 回呼び出されます。最初は無視できる err == -EINPROGRESS で、次に err == 0 で呼び出されます。Sabrina の元のパッチと比較して、このバージョンでは新しい tls_*crypt_async_wait() ヘルパーを使用して、EBUSY を EINPROGRESS に変換しすべてのエラー処理パスを変更する必要を回避します。処理は同じです。(CVE-2024-26584)

  - Linux カーネルでは、次の脆弱性が解決されています。tls: 非同期通知とソケットクローズの間の競合を修正します。送信中のスレッド (recvmsg/sendmsg と呼ばれていた) が、非同期暗号ハンドラーが complete() を呼び出すとすぐに終了する可能性があり、その後のどのコードでもすでに解放されたデータにアクセスする危険があります。ロックと余分なフラグをすべて一緒に回避するようにしてください。メインスレッドに追加の参照を保持させて、同期をアトミック参照カウンターのみに依存させることができます。完了の再初期化を待つ必要はありません。完了が起動するタイミングが厳密に制御されるようになりました。(CVE-2024-26583)

  - Linux カーネルでは、以下の脆弱性が解決されています。i2c: i801: ブロックプロセス呼び出しトランザクションを修正してます。Intel データシートによると、ソフトウェアはブロックプロセス呼び出しトランザクションのブロックバッファインデックスを 2 回リセットしなければなりません。バッファに送信データを書き込む前とバッファから着信データを読み取る前です。ドライバーには現在 2 番目のリセットがないため、ブロックバッファの誤った部分が読み取られます。(CVE-2024-26593)

  - Linux カーネルで、次の脆弱性が解決されています。x86/fpu: 情報についてユーザー空間に依存することを止め、xsave バッファで障害を発生させないようにします。この変更前は、ユーザー空間バッファの予想されるサイズは fx_sw->xstate_size から取得されていました。fx_sw->xstate_size はユーザー空間から変更できるため、次のような状況で sigreturn フレームの構築が可能でした。* fx_sw->xstate_size が、fx_sw->xfeatures の有効なビットによって必要とされるサイズよりも小さい。* ユーザー空間が sigrame fpu バッファの一部のマッピングを解除し、xrstor が必要とするバッファの一部にアクセスできない。この場合、xrstor はマッピングされていない領域を復元してアクセスしようとするため、障害が発生します。しかし、buf + fx_sw->xstate_size がまだマップされている領域内にあり、戻って xrstor を再試行するため、fault_in_readable は成功します。これは無限ループになります。代わりに、XRSTOR が操作できる最大サイズに障害があります (fpstate->user_size から取得)。[dhansen: 件名の調整/変更ログ] (CVE-2024-26603)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ID	名稱	產品	系列	已發布	已更新	嚴重性
191082	Fedora 39 : kernel (2024-d16d94b00d)	Nessus	Fedora Local Security Checks	2024/2/28	2024/3/18	high
191083	Fedora 38 : kernel (2024-71f0f16533)	Nessus	Fedora Local Security Checks	2024/2/28	2024/3/18	high
191082	Fedora 39 : カーネル (2024-d16d94b00d)	Nessus	Fedora Local Security Checks	2024/2/28	2024/3/18	high
191083	Fedora 38 : カーネル (2024-71f0f16533)	Nessus	Fedora Local Security Checks	2024/2/28	2024/3/18	high

偵測

搜尋 Plugin

high

high

high

high