LSN-0110-1

In the Linux kernel, the following vulnerability has been resolved: tty: ngsm: require CAPNETADMIN to attach NGSM0710 ldisc Any unprivileged user can attach NGSM0710 ldisc, but it requires CAPNETADMIN to create a GSM network anyway. Require initial namespace CAPNET_ADMIN to do that.)(CVE-2023-52880)

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6 OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet. OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.)(CVE-2024-38558)

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.)(CVE-2024-53104)

In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.)(CVE-2024-53140)

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcgunpinonline() blkcgunpinonline() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcgparent(blkcg) but it was calling that after blkcgdestroyblkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcgunpinonline+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwbrelease cgwbreleaseworkfn Call Trace: <TASK> dumpstacklvl+0x27/0x80 printreport+0x151/0x710 kasanreport+0xc0/0x100 blkcgunpinonline+0x15a/0x270 cgwbreleaseworkfn+0x194/0x480 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30 </TASK> ... Freed by task 1944: kasansavetrack+0x2b/0x70 kasansavefreeinfo+0x3c/0x50 _kasanslabfree+0x33/0x50 kfree+0x10c/0x330 cssfreerworkfn+0xe6/0xb30 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcgunpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's.)(CVE-2024-56672)

Attila Szász discovered that the HFS+ file system implementation in the Linux Kernel contained a heap overflow vulnerability. An attacker could use a specially crafted file system image that, when mounted, could cause a denial of service (system crash) or possibly execute arbitrary code.)(CVE-2025-0927)