リモートの SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 ホストには、SUSE-SU-2026:4176-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    acl、attr 用のこの更新は、次の問題を修正します:

    - CVE-2026-54369、CVE-2026-54370、CVE-2026-54371:getfattr/setfattr、getfacl/setfacl/chacl、libacl(bsc#1268867)によるシンボリックリンクトラバーサルの権限昇格。

    acl の変更:

    - 2.4.0 への更新(jsc#PED-16501):
     重要な問題の修正:
     - libacl ライブラリ関数 acl_get_file()、acl_set_file()、acl_extended_file()、および acl_delete_def_file() は、パス名引数を受け取り、シンボリックリンクに従います。特権ユーザーがこれらの関数の 1 つを呼び出すと、パス名コンポーネントをコントロールする攻撃者が、ファイルまたはディレクトリをシンボリックリンクで置き換え、操作を別のファイルにリダイレクトする可能性があります。これはローカル権限の昇格につながる可能性があります。
     (CVE-2026-54369、 bsc#1268867)ライブラリ関数は、互換性を損なうことなく修正することはできません。説明されている挙動は意図によるものです。
     その代わりに、acl パッケージのバージョン 2.4.0 では、追加関数acl_get_file_at()、acl_set_file_at()、acl_extended_file_at()、acl_delete_def_file_at() が導入されています。これらの関数はそれぞれ、dirfd ファイル記述子引数と at_flags 引数を受け取り、AT_SYMLINK_NOFOLLOW フラグと AT_EMPTY_PATH フラグを受け入れます。これらの関数を使用して、シンボリックリンクに従うタイミングを制御します。(CVE-2026-54370、 bsc#1268867)さらに、libacl 関数 acl_get_fd()、acl_set_fd()、および acl_extended_fd() 関数は常にアクセス ACL で動作します。このライブラリは以前、ディレクトリファイル記述子のデフォルト ACL で動作する方法を提供していませんでした。新しい関数により、その制限が取り除かれます。
     必要に応じて、これらの新しいライブラリ関数の使用を開始するかどうかは、個々のプログラム次第です。
     - ディレクトリツリーを移動するとき、getfacl、setfacl、chacl、および getfattr ユーティリティは、ツリー内の各ファイルの完全なパス名を構築し、そのパス名を使ってファイルにアクセスします。特権ユーザーがこれらのユーティリティを使用すると、パス名コンポーネントを制御できる攻撃者が、ディレクトリをシンボリックリンクで置き換え、操作を別のファイルにリダイレクトし、ローカルの権限昇格を引き起こす可能性があります。(CVE-2026-54371、 bsc#1268867)これは、ディレクトリファイル記述子を使用し、これらのディレクトリファイル記述子に関連して操作することにより修正されます。
     - 最後のパス名コンポーネントを解決するとき、getfacl、setfacl、chacl、getfattr、および setfattr ユーティリティは、場合によってはシンボリックリンクを解決する関数を使用していました。これには、上記の libacl 関数だけでなく、stat()、chmod()、chown() 関数も含まれます。
     これは、コード全体でシンボリックリンクセーフ関数を使用することで修正されます。
     - バックアップを復元するときに、setfacl および setfattr ユーティリティは、バックアップからのファイルのフルパス名を読み取ります。これらのパス名が解決されると、シンボリックリンクであるパス名コンポーネントがトラバースされました。パス名コンポーネントを制御していた攻撃者が、それをシンボリックリンクで置き換えることで、特権ユーザーに意図したファイル以外のファイルを操作させる可能性があります。
     これにより、前述と同じ種類のローカル権限昇格が発生する可能性があります。
     これは、openat2(RESOLVE_NO_SYMLINKS) を使用してパス名のディレクトリコンポーネントを解決することで修正されますが、詳細については、以下の互換性ノートを参照してください。
    マイナーな問題の修正:
     - シンボリックリンクがコマンドラインで指定されているが、オプション -P(--physical)を使用してシンボリックリンクトラバーサルが無効になっている場合、これまで、getfacl および setfacl ユーティリティはシンボリックリンクを警告なしで無視していました。今では、ELOOP(「シンボリックリンクのレベルが多すぎます」)エラーが代わりに発生します。
     - acl_delete_entry() は、指定されたエントリが指定された ACL に属していることを検証するようになりました。
     - タイプ uid_t と gid_t で表現できない数値 uid と gid は、より慎重にチェックされ、無効な数値は拒否されます。
     - 関数 acl_get_file()、acl_get_file_at()、および acl_get_fd() は、ACL のサイズが予期せず大きくなると、数回再試行します。以前は、割り当てられたバッファを 1 回だけ増やしてから諦めていました。
     - ディレクトリファイル記述子が受け渡されたとき、関数 perm_copy_fd() があるディレクトリから別のディレクトリへデフォルト ACL がコピーされませんでした。現在はサポートしています。
     - setfacl --restore 、ファイル名の中の先頭の空白を不注意に無視していました。現在は発生していません。
     - setfacl --restore--testモードの場合、誤って chmod() を呼び出しました。現在は発生していません。
     - setfattr --restore オプションが複数回使用された場合、バッファが解放されてからアクセスされていました。このような状況が発生することはありません。
     - --restoreの後に setfattr -h(--no-dereference)オプションを指定すると、無視されました。現在は、オプションを任意の順序で渡すことができます。
     - getfattr の -h(--no-dereference)オプションは、getfattr が「シンボリックリンクディレクトリ」に戻るのを防止していました。これは間違っています。dirlink がディレクトリを参照するシンボリックリンクである場合、「getfattr -Rh dirlink」がそのディレクトリにアクセスするようになりました。これを防ぐには、-P(--physical)オプションを使用できます。
     - 同様に、ディレクトリを参照するシンボリックリンクが getfacl または setfacl コマンドラインで指定されると、-R オプションではそのディレクトリがアクセスされませんでした。これが修正され、これらのディレクトリにはアクセスされるようになりました。-P (--physical) オプションを使用することで、

    attr の変更:

    - 2.6.0 への更新(jsc#PED-16501):
    重要な問題の修正:
     - libacl ライブラリ関数 acl_get_file()、acl_set_file()、acl_extended_file()、および acl_delete_def_file() は、パス名引数を受け取り、シンボリックリンクに従います。特権ユーザーがこれらの関数の 1 つを呼び出すと、パス名コンポーネントをコントロールする攻撃者が、ファイルまたはディレクトリをシンボリックリンクで置き換え、操作を別のファイルにリダイレクトする可能性があります。これはローカル権限の昇格につながる可能性があります。
     (CVE-2026-54369、 bsc#1268867)ライブラリ関数は、互換性を損なうことなく修正することはできません。説明されている挙動は意図によるものです。
     その代わりに、acl パッケージのバージョン 2.4.0 では、追加関数acl_get_file_at()、acl_set_file_at()、acl_extended_file_at()、acl_delete_def_file_at() が導入されています。これらの関数はそれぞれ、dirfd ファイル記述子引数と at_flags 引数を受け取り、AT_SYMLINK_NOFOLLOW フラグと AT_EMPTY_PATH フラグを受け入れます。これらの関数を使用して、シンボリックリンクに従うタイミングを制御します。(CVE-2026-54370、 bsc#1268867)さらに、libacl 関数 acl_get_fd()、acl_set_fd()、および acl_extended_fd() 関数は常にアクセス ACL で動作します。このライブラリは以前、ディレクトリファイル記述子のデフォルト ACL で動作する方法を提供していませんでした。新しい関数により、その制限が取り除かれます。
     必要に応じて、これらの新しいライブラリ関数の使用を開始するかどうかは、個々のプログラム次第です。
     - ディレクトリツリーを移動するとき、getfacl、setfacl、chacl、および getfattr ユーティリティは、ツリー内の各ファイルの完全なパス名を構築し、そのパス名を使ってファイルにアクセスします。特権ユーザーがこれらのユーティリティを使用すると、パス名コンポーネントを制御できる攻撃者が、ディレクトリをシンボリックリンクで置き換え、操作を別のファイルにリダイレクトし、ローカルの権限昇格を引き起こす可能性があります。(CVE-2026-54371、 bsc#1268867)これは、ディレクトリファイル記述子を使用し、これらのディレクトリファイル記述子に関連して操作することにより修正されます。
     - 最後のパス名コンポーネントを解決するとき、getfacl、setfacl、chacl、getfattr、および setfattr ユーティリティは、場合によってはシンボリックリンクを解決する関数を使用していました。これには、上記の libacl 関数だけでなく、stat()、chmod()、chown() 関数も含まれます。
     これは、コード全体でシンボリックリンクセーフ関数を使用することで修正されます。
     - バックアップを復元するときに、setfacl および setfattr ユーティリティは、バックアップからのファイルのフルパス名を読み取ります。これらのパス名が解決されると、シンボリックリンクであるパス名コンポーネントがトラバースされました。パス名コンポーネントを制御していた攻撃者が、それをシンボリックリンクで置き換えることで、特権ユーザーに意図したファイル以外のファイルを操作させる可能性があります。
     これにより、前述と同じ種類のローカル権限昇格が発生する可能性があります。
     これは、openat2(RESOLVE_NO_SYMLINKS) を使用してパス名のディレクトリコンポーネントを解決することで修正されますが、詳細については、以下の互換性ノートを参照してください。
    マイナーな問題の修正:
     - シンボリックリンクがコマンドラインで指定されているが、オプション -P(--physical)を使用してシンボリックリンクトラバーサルが無効になっている場合、これまで、getfacl および setfacl ユーティリティはシンボリックリンクを警告なしで無視していました。今では、ELOOP(「シンボリックリンクのレベルが多すぎます」)エラーが代わりに発生します。
     - acl_delete_entry() は、指定されたエントリが指定された ACL に属していることを検証するようになりました。
     - タイプ uid_t と gid_t で表現できない数値 uid と gid は、より慎重にチェックされ、無効な数値は拒否されます。
     - 関数 acl_get_file()、acl_get_file_at()、および acl_get_fd() は、ACL のサイズが予期せず大きくなると、数回再試行します。以前は、割り当てられたバッファを 1 回だけ増やしてから諦めていました。
     - ディレクトリファイル記述子が受け渡されたとき、関数 perm_copy_fd() があるディレクトリから別のディレクトリへデフォルト ACL がコピーされませんでした。現在はサポートしています。
     - setfacl --restore 、ファイル名の中の先頭の空白を不注意に無視していました。現在は発生していません。
     - setfacl --restore--testモードの場合、誤って chmod() を呼び出しました。現在は発生していません。
     - setfattr --restore オプションが複数回使用された場合、バッファが解放されてからアクセスされていました。このような状況が発生することはありません。
     - --restoreの後に setfattr -h(--no-dereference)オプションを指定すると、無視されました。現在は、オプションを任意の順序で渡すことができます。
     - getfattr の -h(--no-dereference)オプションは、getfattr が「シンボリックリンクディレクトリ」に戻るのを防止していました。これは間違っています。dirlink がディレクトリを参照するシンボリックリンクである場合、「getfattr -Rh dirlink」がそのディレクトリにアクセスするようになりました。これを防ぐには、-P(--physical)オプションを使用できます。
     - 同様に、ディレクトリを参照するシンボリックリンクが getfacl または setfacl コマンドラインで指定されると、-R オプションではそのディレクトリがアクセスされませんでした。これが修正され、これらのディレクトリにはアクセスされるようになりました。-P (--physical) オプションを使用することで、
    - 2.5.2 への更新:
     * attr:attr_copy_action() でのデッドストアを排除
     * libattr:属性または asm を通じてレガシー syscall のシンボルバージョンを設定します
     * exports:ライブラリコードに LGPL を使用
     * ドキュメントの更新
     * 翻訳の更新(ポーランド語、オランダ語、グレゴリオ暦、フランス語)
     * ビルドシステムの更新

Tenable は、前述の記述ブロックを SUSE セキュリティアドバイザリから直接抽出しています。

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

検出

SUSE SLED15:acl/attr/libacl-devel/libacl1/libacl1-32bit/libattr-devel/etc(SUSE-SU-2026:4176-1)

high Nessus プラグイン ID 346210

バージョン 1.1