Sicherheitslücken in linux-oracle-6.8 · Seite 200

netfilter: nf_tables: add hook transactions for device deletions

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: add hook transactions for device deletions Restore the flag that indicates that the hook is going away, ie. NFT_HOOK_REMOVE, but add a new transaction object to track deletion of hooks without altering the basechain/flowtable hook_list during the preparation phase. The existing approach that moves the hook from the basechain/flowtable hook_list to transaction hook_list breaks netlink dump path readers of this RCU-protected list. It should be possible use an array for nft_trans_hook to store the deleted hooks to compact the representation but I am not

drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit e2b5499fca55f1a32960a311bbb62e35891eaf73)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 663bed3c7b8b9a7624b0d95d300ddae034ad0614)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/vcn: set no_user_fence for VCN v4.0 enc ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v4.0 enc ring VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit fd852c048b46f9825e904a4f3f4538fe9d8827d9)

drm/amdgpu/vcn: set no_user_fence for VCN v4.0.3 enc ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v4.0.3 enc ring VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit ff1a5a125c5a70c328806b9bc01d7d942cf3f9aa)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/vcn: set no_user_fence for VCN v4.0.5 enc ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v4.0.5 enc ring VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 084d94ac93707bdda07efb5cee786f632de4219b)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 96179da0c6b059eb31706a0abe8dd6381c533143)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 3216a7f4e2642bda5fd14f57586e835ae9202587)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 2f6afc97d259d530f4f86c7743efbc573a8da927)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.5 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.5 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit f05d0a4f21fc720116d6e238f23308b199891058)

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

ASoC: rsnd: Fix potential out-of-bounds access of component_dais[]

In the Linux kernel, the following vulnerability has been resolved: ASoC: rsnd: Fix potential out-of-bounds access of component_dais[] component_dais[RSND_MAX_COMPONENT] is initially zero-initialized and later populated in rsnd_dai_of_node(). However, the existing boundary check: if (i >= RSND_MAX_COMPONENT) does not guarantee that the last valid element remains zero. As a result, the loop can rely on component_dais[RSND_MAX_COMPONENT] being zero, which may lead to an out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.

• Auf 6.8.0-1058.61~22.04.1 aktualisieren

batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the

batman-adv: v: prevent OGM aggregation on disabled hardif

In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function mus

batman-adv: tp_meter: restrict number of unacked list entries

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger

ntfs3: reject direct userspace writes to reserved $LX* xattrs

In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_sav

mac802154: llsec: add skb_cow_data() before in-place crypto

In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802

net: skmsg: preserve sg.copy across SG transforms

In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdic