kernel-3.10.0-1160.119.1.0.12.el7.AXS7
エラータID: AXSA:2025-10504:42
以下項目について対処しました。
[Security Fix]
- RDMA/srpt には、稀にメモリの解放後利用を起こす問題があるため、
ローカルの攻撃者により、イベントハンドラーを介して、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-26872)
- NFS には、nfs_direct_request の完了処理を二重実行していること
に起因したメモリ領域の解放後利用の問題があるため、ローカルの攻撃
者により、サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-26958)
- fs/squashfs/inode.c の squashfs_new_inode() 関数には、inode
番号のチェック処理漏れに起因したメモリ領域の範囲外アクセスの問題が
あるため、ローカルの攻撃者により、サービス拒否攻撃を可能とする脆弱性
が存在します。(CVE-2024-26982)
- Netfilter サブシステムには、入力されたサイズのチェック処理が
欠落しているため、ローカルの攻撃者により、サービス拒否攻撃を可能と
する脆弱性が存在します。(CVE-2024-35896)
- xfs には、境界のチェックの欠落によるメモリの境界外アクセスの
問題があるため、ローカルの攻撃者により、ファイルシステムの操作を
介して、サービス妨害を可能とする脆弱性が存在します。
(CVE-2024-41014)
- net/sched/sch_fifo.c の pfifo_tail_enqueue() 関数には、
スケジューラーの制限に達した場合のチェック処理、およびキュー内の
パケットのドロップ処理が欠落しているため、ローカルの攻撃者により、
特権昇格を可能とする脆弱性が存在します。(CVE-2025-21702)
パッケージをアップデートしてください。
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.
In the Linux kernel, the following vulnerability has been resolved: nfs: fix UAF in direct writes In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace:
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix]
In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace:
In the Linux kernel, the following vulnerability has been resolved: xfs: add bounds checking to xlog_recover_process_data There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header.
In the Linux kernel, the following vulnerability has been resolved: pfifo_tail_enqueue: Drop new packet when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
N/A
Asianux Server 7 for x86_64
- bpftool-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 9d8b5763c6eeed4be78f787c019f92c1
SHA-256: e91e857f7515874362801a1af28a6adaab467ff59a63e387fdcc69e8d0fb81db
Size: 8.55 MB - kernel-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: b56f7fd52e44a162aca5a4a185484285
SHA-256: d9d908a576ebb5906da883f0e1521028a26bf4559e0b8134574ffaa0097548c7
Size: 51.76 MB - kernel-abi-whitelists-3.10.0-1160.119.1.0.12.el7.AXS7.noarch.rpm
MD5: 62c2287b8d8fe96c3cf8f9f41c514a37
SHA-256: def62d43f7c28768b6492e6d3124f74b093c1958edd48832dfbf37df5c8455d2
Size: 8.11 MB - kernel-debug-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 1a76f2e53e577019ab9983511ecc9afb
SHA-256: 9e9d2510db965b2d8125d4ec0109d2e80cd678e000bb3dfb4a8571621314e669
Size: 54.05 MB - kernel-debug-devel-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 668b53bc4a3d23edd83503fba90da2fa
SHA-256: 823f5d56bc585ea9078f53ad6050ab099e1636165f5e404fe5c4b0ad4e709a85
Size: 18.15 MB - kernel-devel-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 90ca791aec76bcef298799d4e69a855e
SHA-256: f2b5896456ecd4db6cde360f55c3814de9d8c4a1300224092ca510d59273c875
Size: 18.09 MB - kernel-doc-3.10.0-1160.119.1.0.12.el7.AXS7.noarch.rpm
MD5: 7726e56d2ed2f181afa833381c611de6
SHA-256: 24a37cd4d786d8fbb19b3235a2f11ee7aa70149a71e1f36276e365a7b301b7db
Size: 19.59 MB - kernel-headers-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: d5556c7c02bd4d910c9b40d767705836
SHA-256: 9fafa3e2b419cc4ba249f8738b2ca937d1e109bff4a17134e3420c22e799a971
Size: 9.10 MB - kernel-tools-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 937849bf7281e279e7a81521ae05d4a8
SHA-256: a4c67ae5c70c7d4e692199698b7c307f89df274ab1774fa1636fac358a5d8362
Size: 8.21 MB - kernel-tools-libs-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: ae1a68908524d2d679806b75a7a0ce21
SHA-256: 186c01f0105c5c79ded99b85bc67819b4efd1853f70c8e1380b4a67703a3f619
Size: 8.11 MB - perf-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 3ba5e662e51bf66cb81e43aaa36b853a
SHA-256: a9f27492110c91af928429edb6ced4c0fa8352b20cfd144c295838180ce8873e
Size: 9.75 MB - python-perf-3.10.0-1160.119.1.0.12.el7.AXS7.x86_64.rpm
MD5: 12b17006077cd0f2d11116e413a96807
SHA-256: abf71adf65b43650bc740c45e13a6f06867933684ff8c2993b2ec0d7760877cd
Size: 8.20 MB