kernel-5.14.0-503.15.1.el9_5
エラータID: AXSA:2025-9526:02
リリース日:
2025/01/08 Wednesday - 10:51
題名:
kernel-5.14.0-503.15.1.el9_5
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
Moderate
Description:
以下項目について対処しました。
[Security Fix]
- kernel/bpf/ringbuf.c には、リングバッファの参照先ページ
の算出処理のロジックに問題があるため、ローカルの攻撃者
により、サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-41009)
- drivers/usb/serial/mos7840.c には、レジューム処理に
クラッシュを起こす問題があるため、ローカルの攻撃者に
より、巧妙に細工されたデバイスを介して、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-42244)
- cxl ドライバーには、メモリ領域の解放後利用の問題がある
ため、ローカルの攻撃者により、サービス拒否攻撃 (カーネル
クラッシュの発生) を可能とする脆弱性が存在します。
(CVE-2024-50226)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2024-41009
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
CVE-2024-42244
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
CVE-2024-50226
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the "out of order reset case" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace:
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-503.15.1.el9_5.src.rpm
MD5: b3743d2cc327956d9ef1630bfaa62e5b
SHA-256: c16d1629b5c2886c004dde8ddd0672c4e9fa383ca3642ba4c91d8eca3dbe4f1e
Size: 141.80 MB
Asianux Server 9 for x86_64
- bpftool-7.4.0-503.15.1.el9_5.x86_64.rpm
MD5: f1fdef9f0d6d45a146c27c18640efe43
SHA-256: 0494fbc5fdff2f53503aad1eca501f46c35892a53b36c49c546cf2f88b4b25a8
Size: 2.78 MB - kernel-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 845e629b19b58481c443b37ae632ec27
SHA-256: 8da83b817e4f9cfdee7cfa343db0135914b9507e75afa41945052e46d736a95a
Size: 2.01 MB - kernel-abi-stablelists-5.14.0-503.15.1.el9_5.noarch.rpm
MD5: d212432c1712f24b4f196f1c3a32302e
SHA-256: 9253ebf2c8b92b4a6882dc785ddc33c4dd14cd7247f49b30317eeb7c780493dc
Size: 2.03 MB - kernel-core-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: a4b02cb1bd0ba31df8ce2022da32e9df
SHA-256: df1989515b356ae624d090f4763bd65567601d604e546b5b58375d13eeb5b0b3
Size: 17.63 MB - kernel-cross-headers-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 5344761a845696208af1e653a91aba92
SHA-256: e1273a7d6203ca916512946dc4460149e21fa0f1af9bd4741ee8661e4dd6e76e
Size: 8.76 MB - kernel-debug-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 447fc908e017a33e8eccf1d4179972ff
SHA-256: 61124de06bd169f72b18a36351e23d6cc217c16063dc25adfa4836fc5b0b96bf
Size: 2.01 MB - kernel-debug-core-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 9c0dcffe56a9192be7f07170481fb8da
SHA-256: 4ecb109780bd20f49455f57e6a2015beb67c6e788d5e7db0ce7ac81dcbfc8c48
Size: 30.69 MB - kernel-debug-devel-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 960bccb1d9493bdd03a16e5f937c6310
SHA-256: 4c116799b7eeec40a7a84257ee96f825fa20efa5a7cdb480875a68a07332e16e
Size: 21.74 MB - kernel-debug-devel-matched-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: c1a76b3bacc465a7050895e4997569ca
SHA-256: e7daaee01b686e1d5e33ea1bb60d2d6255ed864ac0714fba58a68f5a1b590dfe
Size: 2.01 MB - kernel-debug-modules-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 2b5cd71707d182967f5da31a30824ae7
SHA-256: 3e0893eafe23b3478924e1b3e4ec54b75fa839039f565e0ee7656c27cc0242bd
Size: 62.64 MB - kernel-debug-modules-core-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 152a6fb5de9e18f1573ead9cda40acf2
SHA-256: c97b65410184a3abefbdef58bbf015629b8fe8a4c9baf4f8311a875ddb6f507b
Size: 47.97 MB - kernel-debug-modules-extra-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 1c2730dee589733f99e88385d6903f30
SHA-256: 8648e76b494a6083ae32b0352f7b98287fe21affaa5a67e0e89c22565e1b1c9b
Size: 2.87 MB - kernel-debug-uki-virt-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: a93798afadef6a19bbd1544246472313
SHA-256: 0c6d512d66008e3b325913d3138f3d4d52f006e61df4d10a45870d4aec7942b0
Size: 81.29 MB - kernel-devel-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: ff586c2218b87a2ee1df49a72a682390
SHA-256: 95caa954f07637442fc68b2aba410c07a5b3492ed6ab327e7c81e2f87b6b5147
Size: 21.54 MB - kernel-devel-matched-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 760d73013e6f4e6689356cc2ec8935ba
SHA-256: 3f3721785575859d99b64fe728c87b639a90934c657ef334e46a2154e384c98f
Size: 2.01 MB - kernel-doc-5.14.0-503.15.1.el9_5.noarch.rpm
MD5: cf5764796023226fd805ed7e6bf868e7
SHA-256: 8d13cd2e05d4e79aa8fcb71892722b85111283272800838cf51f975e60baef18
Size: 37.41 MB - kernel-headers-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: d1d2e58e56f7c7da10b95eeb41a1959e
SHA-256: f47d23afb7557a3953cd541a6699f8b391aa1e736980c0b29c93598051bd89c9
Size: 3.72 MB - kernel-modules-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 4d7885edf7b2b13b306556c1d1c684b0
SHA-256: 161bbd59cdf181cde24b3be376a243cc72ee1dc1bb8098e3fe94842b725be00c
Size: 36.53 MB - kernel-modules-core-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 55207cac5a38d8235b464229398f4d83
SHA-256: 698cf2b31542f6e99c48adc838d74c208ebcfc7051b8b1984a847beb05caa812
Size: 30.42 MB - kernel-modules-extra-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: a78821c01d51e268254f1e1ac3938afe
SHA-256: 1a47c02516d7c94f88415de55ee02d33804a23b204bf8357fb1d47103b92f742
Size: 2.48 MB - kernel-tools-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 54e0a6cd82dc9c7784adea7dd9e48761
SHA-256: 3eab276674b46badf10eea7631d1ae170bb1e039c1582f0c7f3f2b5ebcf45dec
Size: 2.28 MB - kernel-tools-libs-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 49e559da61691a22ac0cd8a5205b00d5
SHA-256: dcabd79122fde402822449d392190461192fe1b06da11a2b438fb2b39ad7f007
Size: 2.02 MB - kernel-tools-libs-devel-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: ecaff7e4de0c82e0c4bfef3788eb4072
SHA-256: 2de23f7c469b8c406ea5c6538c84788e2bd8f1e57252ee32fb00334875ced49e
Size: 2.01 MB - kernel-uki-virt-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: fbd694708991071b8a5447f61b0a91c0
SHA-256: d732ecf66f324e447c4beb1b1cc2948e27f54f3386d8f869530282aabc03c7fc
Size: 60.46 MB - kernel-uki-virt-addons-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 3ebca955346872b2f77c572c41451d9c
SHA-256: 1622b702df6e9be249b602db837ed8fb09e2e06cc84464360013587ed32f3a13
Size: 2.03 MB - libperf-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 2d741ec8083a4bc8558151934cbbc0e1
SHA-256: 1bf4b340a954ab66388f48b7d77cc741bb310514bfb91d75cd7627be4650cd18
Size: 2.03 MB - perf-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: bc743b7f023a880b9b7816b2c3cb81bd
SHA-256: 52c87c72641f9156d89d34c44831de0d8be49b664182d0c4eb20c8304e9c753a
Size: 4.19 MB - python3-perf-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: a8b92c5cc90bbb8319b545dc27b0e9dd
SHA-256: 090575a516f071c175926596ceb041c8918d20bdb3cfe7738c448455d0546d55
Size: 2.11 MB - rtla-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 8ad9b79abaa30b23a8f8ebad8d7315c7
SHA-256: 0e6c2ea46b64b7d94a7b9ae22293d006da373230f21eb2544e00e901f2911b78
Size: 2.06 MB - rv-5.14.0-503.15.1.el9_5.x86_64.rpm
MD5: 0156cfd1453c24c4d7ac4c0ac76ddd61
SHA-256: 52cd0ae2874cef86632a336d8f870f96558ade4c33156186e7646a3a6c350f42
Size: 2.02 MB