Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix use-after-free in ublk_partition_scan_work<br /> <br /> A race condition exists between the async partition scan work and device<br /> teardown that can lead to a use-after-free of ub-&gt;ub_disk:<br /> <br /> 1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()<br /> 2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:<br /> - del_gendisk(ub-&gt;ub_disk)<br /> - ublk_detach_disk() sets ub-&gt;ub_disk = NULL<br /> - put_disk() which may free the disk<br /> 3. The worker ublk_partition_scan_work() then dereferences ub-&gt;ub_disk<br /> leading to UAF<br /> <br /> Fix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold<br /> a reference to the disk during the partition scan. The spinlock in<br /> ublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker<br /> either gets a valid reference or sees NULL and exits early.<br /> <br /> Also change flush_work() to cancel_work_sync() to avoid running the<br /> partition scan work unnecessarily when the disk is already detached.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: provide locking for v4_end_grace<br /> <br /> Writing to v4_end_grace can race with server shutdown and result in<br /> memory being accessed after it was freed - reclaim_str_hashtbl in<br /> particularly.<br /> <br /> We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is<br /> held while client_tracking_op-&gt;init() is called and that can wait for<br /> an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a<br /> deadlock.<br /> <br /> nfsd4_end_grace() is also called by the landromat work queue and this<br /> doesn&amp;#39;t require locking as server shutdown will stop the work and wait<br /> for it before freeing anything that nfsd4_end_grace() might access.<br /> <br /> However, we must be sure that writing to v4_end_grace doesn&amp;#39;t restart<br /> the work item after shutdown has already waited for it. For this we<br /> add a new flag protected with nn-&gt;client_lock. It is set only while it<br /> is safe to make client tracking calls, and v4_end_grace only schedules<br /> work while the flag is set with the spinlock held.<br /> <br /> So this patch adds a nfsd_net field "client_tracking_active" which is<br /> set as described. Another field "grace_end_forced", is set when<br /> v4_end_grace is written. After this is set, and providing<br /> client_tracking_active is set, the laundromat is scheduled.<br /> This "grace_end_forced" field bypasses other checks for whether the<br /> grace period has finished.<br /> <br /> This resolves a race which can result in use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: detach and close netdevs while handling a reset<br /> <br /> Protect the reset path from callbacks by setting the netdevs to detached<br /> state and close any netdevs in UP state until the reset handling has<br /> completed. During a reset, the driver will de-allocate resources for the<br /> vport, and there is no guarantee that those will recover, which is why the<br /> existing vport_ctrl_lock does not provide sufficient protection.<br /> <br /> idpf_detach_and_close() is called right before reset handling. If the<br /> reset handling succeeds, the netdevs state is recovered via call to<br /> idpf_attach_and_open(). If the reset handling fails the netdevs remain<br /> down. The detach/down calls are protected with RTNL lock to avoid racing<br /> with callbacks. On the recovery side the attach can be done without<br /> holding the RTNL lock as there are no callbacks expected at that point,<br /> due to detach/close always being done first in that flow.<br /> <br /> The previous logic restoring the netdevs state based on the<br /> IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence<br /> the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is<br /> still being used to restore the state of the netdevs following the reset,<br /> but has no use outside of the reset handling flow.<br /> <br /> idpf_init_hard_reset() is converted to void, since it was used as such and<br /> there is no error handling being done based on its return value.<br /> <br /> Before this change, invoking hard and soft resets simultaneously will<br /> cause the driver to lose the vport state:<br /> ip -br a<br /> UP<br /> echo 1 &gt; /sys/class/net/ens801f0/device/reset&amp; \<br /> ethtool -L ens801f0 combined 8<br /> ip -br a<br /> DOWN<br /> ip link set up<br /> ip -br a<br /> DOWN<br /> <br /> Also in case of a failure in the reset path, the netdev is left<br /> exposed to external callbacks, while vport resources are not<br /> initialized, leading to a crash on subsequent ifup/down:<br /> [408471.398966] idpf 0000:83:00.0: HW reset detected<br /> [408471.411744] idpf 0000:83:00.0: Device HW Reset initiated<br /> [408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device&amp;#39;s firmware. Check that the FW is running. Driver state= 0x2<br /> [408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078<br /> [408508.126112] #PF: supervisor read access in kernel mode<br /> [408508.126687] #PF: error_code(0x0000) - not-present page<br /> [408508.127256] PGD 2aae2f067 P4D 0<br /> [408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI<br /> ...<br /> [408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]<br /> ...<br /> [408508.139193] Call Trace:<br /> [408508.139637] <br /> [408508.140077] __dev_close_many+0xbb/0x260<br /> [408508.140533] __dev_change_flags+0x1cf/0x280<br /> [408508.140987] netif_change_flags+0x26/0x70<br /> [408508.141434] dev_change_flags+0x3d/0xb0<br /> [408508.141878] devinet_ioctl+0x460/0x890<br /> [408508.142321] inet_ioctl+0x18e/0x1d0<br /> [408508.142762] ? _copy_to_user+0x22/0x70<br /> [408508.143207] sock_do_ioctl+0x3d/0xe0<br /> [408508.143652] sock_ioctl+0x10e/0x330<br /> [408508.144091] ? find_held_lock+0x2b/0x80<br /> [408508.144537] __x64_sys_ioctl+0x96/0xe0<br /> [408508.144979] do_syscall_64+0x79/0x3d0<br /> [408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [408508.145860] RIP: 0033:0x7f3e0bb4caff

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: Fix crash when adding interface under a lag<br /> <br /> Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")<br /> fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.<br /> The ocelot_set_aggr_pgids() function in the ocelot driver has similar logic<br /> and is susceptible to the same crash.<br /> <br /> This issue specifically affects the ocelot_vsc7514.c frontend, which leaves<br /> unused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected as<br /> it uses the DSA framework which registers all ports.<br /> <br /> Fix this by checking if the port pointer is valid before accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not write to msg_get_inq in callee<br /> <br /> NULL pointer dereference fix.<br /> <br /> msg_get_inq is an input field from caller to callee. Don&amp;#39;t set it in<br /> the callee, as the caller may not clear it on struct reuse.<br /> <br /> This is a kernel-internal variant of msghdr only, and the only user<br /> does reinitialize the field. So this is not critical for that reason.<br /> But it is more robust to avoid the write, and slightly simpler code.<br /> And it fixes a bug, see below.<br /> <br /> Callers set msg_get_inq to request the input queue length to be<br /> returned in msg_inq. This is equivalent to but independent from the<br /> SO_INQ request to return that same info as a cmsg (tp-&gt;recvmsg_inq).<br /> To reduce branching in the hot path the second also sets the msg_inq.<br /> That is WAI.<br /> <br /> This is a fix to commit 4d1442979e4a ("af_unix: don&amp;#39;t post cmsg for<br /> SO_INQ unless explicitly asked for"), which fixed the inverse.<br /> <br /> Also avoid NULL pointer dereference in unix_stream_read_generic if<br /> state-&gt;msg is NULL and msg-&gt;msg_get_inq is written. A NULL state-&gt;msg<br /> can happen when splicing as of commit 2b514574f7e8 ("net: af_unix:<br /> implement splice for stream af_unix sockets").<br /> <br /> Also collapse two branches using a bitwise or.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: prevent potential out-of-bounds reads in handle_auth_done()<br /> <br /> Perform an explicit bounds check on payload_len to avoid a possible<br /> out-of-bounds access in the callout.<br /> <br /> [ idryomov: changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: Fix RSS LUT NULL pointer crash on early ethtool operations<br /> <br /> The RSS LUT is not initialized until the interface comes up, causing<br /> the following NULL pointer crash when ethtool operations like rxhash on/off<br /> are performed before the interface is brought up for the first time.<br /> <br /> Move RSS LUT initialization from ndo_open to vport creation to ensure LUT<br /> is always available. This enables RSS configuration via ethtool before<br /> bringing the interface up. Simplify LUT management by maintaining all<br /> changes in the driver&amp;#39;s soft copy and programming zeros to the indirection<br /> table when rxhash is disabled. Defer HW programming until the interface<br /> comes up if it is down during rxhash and LUT configuration changes.<br /> <br /> Steps to reproduce:<br /> ** Load idpf driver; interfaces will be created<br /> modprobe idpf<br /> ** Before bringing the interfaces up, turn rxhash off<br /> ethtool -K eth2 rxhash off<br /> <br /> [89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [89408.371908] #PF: supervisor read access in kernel mode<br /> [89408.371924] #PF: error_code(0x0000) - not-present page<br /> [89408.371940] PGD 0 P4D 0<br /> [89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI<br /> <br /> [89408.372052] RIP: 0010:memcpy_orig+0x16/0x130<br /> [89408.372310] Call Trace:<br /> [89408.372317] <br /> [89408.372326] ? idpf_set_features+0xfc/0x180 [idpf]<br /> [89408.372363] __netdev_update_features+0x295/0xde0<br /> [89408.372384] ethnl_set_features+0x15e/0x460<br /> [89408.372406] genl_family_rcv_msg_doit+0x11f/0x180<br /> [89408.372429] genl_rcv_msg+0x1ad/0x2b0<br /> [89408.372446] ? __pfx_ethnl_set_features+0x10/0x10<br /> [89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [89408.372482] netlink_rcv_skb+0x58/0x100<br /> [89408.372502] genl_rcv+0x2c/0x50<br /> [89408.372516] netlink_unicast+0x289/0x3e0<br /> [89408.372533] netlink_sendmsg+0x215/0x440<br /> [89408.372551] __sys_sendto+0x234/0x240<br /> [89408.372571] __x64_sys_sendto+0x28/0x30<br /> [89408.372585] x64_sys_call+0x1909/0x1da0<br /> [89408.372604] do_syscall_64+0x7a/0xfa0<br /> [89408.373140] ? clear_bhb_loop+0x60/0xb0<br /> [89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [89408.378887] <br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: fix race condition for gdev-&gt;srcu<br /> <br /> If two drivers were calling gpiochip_add_data_with_key(), one may be<br /> traversing the srcu-protected list in gpio_name_to_desc(), meanwhile<br /> other has just added its gdev in gpiodev_add_to_list_unlocked().<br /> This creates a non-mutexed and non-protected timeframe, when one<br /> instance is dereferencing and using &amp;gdev-&gt;srcu, before the other<br /> has initialized it, resulting in crash:<br /> <br /> [ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000<br /> [ 4.943396] Mem abort info:<br /> [ 4.943400] ESR = 0x0000000096000005<br /> [ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.943407] SET = 0, FnV = 0<br /> [ 4.943410] EA = 0, S1PTW = 0<br /> [ 4.943413] FSC = 0x05: level 1 translation fault<br /> [ 4.943416] Data abort info:<br /> [ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000<br /> [ 4.961449] [ffff800272bcc000] pgd=0000000000000000<br /> [ 4.969203] , p4d=1000000039739003<br /> [ 4.979730] , pud=0000000000000000<br /> [ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset"<br /> [ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> ...<br /> [ 5.121359] pc : __srcu_read_lock+0x44/0x98<br /> [ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0<br /> [ 5.153671] sp : ffff8000833bb430<br /> [ 5.298440]<br /> [ 5.298443] Call trace:<br /> [ 5.298445] __srcu_read_lock+0x44/0x98<br /> [ 5.309484] gpio_name_to_desc+0x60/0x1a0<br /> [ 5.320692] gpiochip_add_data_with_key+0x488/0xf00<br /> 5.946419] ---[ end trace 0000000000000000 ]---<br /> <br /> Move initialization code for gdev fields before it is added to<br /> gpio_devices, with adjacent initialization code.<br /> Adjust goto statements to reflect modified order of operations<br /> <br /> [Bartosz: fixed a build issue, removed stray newline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: avoid dereferencing ERR_PTR in tcf_idrinfo_destroy<br /> <br /> syzbot reported a crash in tc_act_in_hw() during netns teardown where<br /> tcf_idrinfo_destroy() passed an ERR_PTR(-EBUSY) value as a tc_action<br /> pointer, leading to an invalid dereference.<br /> <br /> Guard against ERR_PTR entries when iterating the action IDR so teardown<br /> does not call tc_act_in_hw() on an error pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arp: do not assume dev_hard_header() does not change skb-&gt;head<br /> <br /> arp_create() is the only dev_hard_header() caller<br /> making assumption about skb-&gt;head being unchanged.<br /> <br /> A recent commit broke this assumption.<br /> <br /> Initialize @arp pointer after dev_hard_header() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: check that server is running in unlock_filesystem<br /> <br /> If we are trying to unlock the filesystem via an administrative<br /> interface and nfsd isn&amp;#39;t running, it crashes the server. This<br /> happens currently because nfsd4_revoke_states() access state<br /> structures (eg., conf_id_hashtbl) that has been freed as a part<br /> of the server shutdown.<br /> <br /> [ 59.465072] Call trace:<br /> [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)<br /> [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]<br /> [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]<br /> [ 59.466780] vfs_write+0x1f0/0x938<br /> [ 59.467088] ksys_write+0xfc/0x1f8<br /> [ 59.467395] __arm64_sys_write+0x74/0xb8<br /> [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8<br /> [ 59.468177] do_el0_svc+0x154/0x1d8<br /> [ 59.468489] el0_svc+0x40/0xe0<br /> [ 59.468767] el0t_64_sync_handler+0xa0/0xe8<br /> [ 59.469138] el0t_64_sync+0x1ac/0x1b0<br /> <br /> Ensure this can&amp;#39;t happen by taking the nfsd_mutex and checking that<br /> the server is still up, and then holding the mutex across the call to<br /> nfsd4_revoke_states().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity: disable recursive forward error correction<br /> <br /> There are two problems with the recursive correction:<br /> <br /> 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that<br /> has 253 iterations. For each iteration, we may call verity_hash_for_block<br /> recursively. There is a limit of 4 nested recursions - that means that<br /> there may be at most 253^4 (4 billion) iterations. Red Hat QE team<br /> actually created an image that pushes dm-verity to this limit - and this<br /> image just makes the udev-worker process get stuck in the &amp;#39;D&amp;#39; state.<br /> <br /> 2. It doesn&amp;#39;t work. In fec_read_bufs we store data into the variable<br /> "fio-&gt;bufs", but fio bufs is shared between recursive invocations, if<br /> "verity_hash_for_block" invoked correction recursively, it would<br /> overwrite partially filled fio-&gt;bufs.