OESA-2024-1835

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

usb: fix various gadgets null ptr deref on 10gbps cabling.

This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps.(CVE-2021-47270)

In the Linux kernel, the following vulnerability has been resolved:

seg6: fix the iif in the IPv6 socket control block

When an IPv4 packet is received, the iprcvcore(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510):

IPCB(skb)->iif = skb->skb_iif;

If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6dosrhencap(...) performs the required encapsulation. In this case, the seg6dosrhencap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):

memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));

The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).

Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero).

As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied.

To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.(CVE-2021-47515)

In the Linux kernel, the following vulnerability has been resolved:

media: mxl111sf: change mutex_init() location

Syzbot reported, that mxl111sfctrlmsg() uses uninitialized mutex. The problem was in wrong mutex_init() location.

Previous mutexinit(&state->msglock) call was in ->init() function, but dvbusbv2init() has this order of calls:

dvb_usbv2_init()
  dvb_usbv2_adapter_init()
    dvb_usbv2_adapter_frontend_init()
      props->frontend_attach()

  props->init()

Since mxl111sf* devices call mxl111sfctrlmsg() in ->frontendattach() internally we need to initialize state->msglock before frontendattach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex.(CVE-2021-47583)

In the Linux kernel, the following vulnerability has been resolved:

mac80211: validate extended element ID is present

Before attempting to parse an extended element, verify that the extended element ID is present.(CVE-2021-47611)

In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix queues reservation for XDP

When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference.

i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40exdp+0xea/0x1b0 [i40e] Call Trace: ? i40ereconfigrssqueues+0x130/0x130 [i40e] devxdpinstall+0x61/0xe0 devxdpattach+0x18a/0x4c0 devchangexdpfd+0x1e6/0x220 dosetlink+0x616/0x1030 ? ahciportstop+0x80/0x80 ? ataqcissue+0x107/0x1e0 ? locktimerbase+0x61/0x80 ? _modtimer+0x202/0x380 rtnlsetlink+0xe5/0x170 ? bpflsmbindertransaction+0x10/0x10 ? securitycapable+0x36/0x50 rtnetlinkrcvmsg+0x121/0x350 ? rtnlcalcit.isra.0+0x100/0x100 netlinkrcvskb+0x50/0xf0 netlinkunicast+0x1d3/0x2a0 netlinksendmsg+0x22a/0x440 socksendmsg+0x5e/0x60 _syssendto+0xf0/0x160 ? _sysgetsockname+0x7e/0xc0 ? _copyfromuser+0x3c/0x80 ? _syssetsockopt+0xc8/0x1a0 _x64syssendto+0x20/0x30 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0

This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on.

Fix this by always allocating last queue in PF queue pile for a flow director VSI.(CVE-2021-47619)

In the Linux kernel, the following vulnerability has been resolved:

ASoC: max9759: fix underflow in speakergaincontrol_put()

Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> sndctlelemwriteuser() -> sndctlelem_write() -> kctl->put()(CVE-2022-48717)

In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: ca8210: Stop leaking skb's

Upon error the ieee802154xmitcomplete() helper is not called. Only ieee802154wakequeue() is called manually. We then leak the skb structure.

Free the skb structure upon error before returning.(CVE-2022-48722)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2022-48736)

In the Linux kernel, the following vulnerability has been resolved:

ASoC: ops: Reject out of bounds values in sndsocput_volsw()

We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.(CVE-2022-48738)

In the Linux kernel, the following vulnerability has been resolved:

net: amd-xgbe: Fix skb data length underflow

There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected.

Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors.(CVE-2022-48743)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Avoid field-overflowing memcpy()

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields.

Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler.

We were doing:

#define ETH_HLEN  14
#define VLAN_HLEN  4
...
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
...
    struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
...
    struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;
    struct mlx5_wqe_data_seg *dseg = wqe->data;
...
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);

target is wqe->eth.inlinehdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlantci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes).

struct mlx5etxwqe { struct mlx5wqectrlseg ctrl; /* 0 16 */ struct mlx5wqeethseg eth; /* 16 16 / struct mlx5_wqe_data_seg data[]; / 32 0 */

    /* size: 32, cachelines: 1, members: 3 */
    /* last cacheline: 32 bytes */

};

struct mlx5wqeethseg { u8 swpouterl4offset; /* 0 1 / u8 swp_outer_l3_offset; / 1 1 / u8 swp_inner_l4_offset; / 2 1 / u8 swp_inner_l3_offset; / 3 1 / u8 cs_flags; / 4 1 / u8 swp_flags; / 5 1 / __be16 mss; / 6 2 / __be32 flow_table_metadata; / 8 4 / union { struct { __be16 sz; / 12 2 / u8 start[2]; / 14 2 / } inline_hdr; / 12 4 / struct { __be16 type; / 12 2 / __be16 vlan_tci; / 14 2 / } insert; / 12 4 / __be32 trailer; / 12 4 / }; / 12 4 */

    /* size: 16, cachelines: 1, members: 9 */
    /* last cacheline: 16 bytes */

};

struct mlx5wqedataseg { _be32 bytecount; /* 0 4 */ _be32 lkey; /* 4 4 / __be64 addr; / 8 8 */

    /* size: 16, cachelines: 1, members: 3 */
    /* last cacheline: 16 bytes */

};

So, split the memcpy() so the compiler can reason about the buffer sizes.

"pahole" shows no size nor member offset changes to struct mlx5etxwqe nor struct mlx5eumrwqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations).(CVE-2022-48744)

In the Linux kernel, the following vulnerability has been resolved:

scsi: bnx2fc: Flush destroywork queue before calling bnx2fcinterface_put()

The bnx2fcdestroy() functions are removing the interface before calling destroywork. This results multiple WARNings from sysfsremovegroup() as the controller rport device attributes are removed too early.

Replace the fcoeport's destroywork queue. It's not needed.

The problem is easily reproducible with the following steps.

Example:

$ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfsremovegroup+0x6f/0x80 [ 583.607130] Modules linked in: dmservicetime 8021q garp mrp stp llc bnx2fc cnic uio rpcsecgsskrb5 authrpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x8664 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fcwq2 fcrportfinaldelete [scsitransportfc] [ 584.050691] RIP: 0010:sysfsremovegroup+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] devicedel+0xb2/0x3e0 [ 584.481701] deviceunregister+0x13/0x60 [ 584.501306] bsgunregisterqueue+0x5b/0x80 [ 584.522029] bsgremovequeue+0x1c/0x40 [ 584.541884] fcrportfinaldelete+0xf3/0x1d0 [scsitransportfc] [ 584.573823] processonework+0x1e3/0x3b0 [ 584.592396] workerthread+0x50/0x3b0 [ 584.609256] ? rescuerthread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? setkthreadstruct+0x40/0x40 [ 584.662909] retfromfork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]---(CVE-2022-48758)

In the Linux kernel, the following vulnerability has been resolved:

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dumpstacklvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] printreport.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasanreport+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasancheckrange+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306aprobe+0x52/0x310 [ 29.616339] i2cdevice_probe+0x951/0xa90(CVE-2022-48772)

In the Linux kernel, the following vulnerability has been resolved:

mmc: sdio: fix possible resource leaks in some error paths

If sdioaddfunc() or sdioinitfunc() fails, sdioremovefunc() can not release the resources, because the sdio function is not presented in these two cases, it won't call ofnodeput() or put_device().

To fix these leaks, make sdiofuncpresent() only control whether devicedel() needs to be called or not, then always call ofnodeput() and putdevice().

In error case in sdioinitfunc(), the reference of 'card->dev' is not get, to avoid redundant put in sdiofreefunccis(), move the getdevice() to sdioallocfunc() and putdevice() to sdiorelease_func(), it can keep the get/put function be balanced.

Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone.

unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloctrace+0x21/0x110 [<000000002f839ccb>] mmcalloccard+0x38/0xb0 [mmccore] [<0000000004adcbf6>] mmcsdioinitcard+0xde/0x170 [mmccore] [<000000007538fea0>] mmcattachsdio+0xcb/0x1b0 [mmccore] [<00000000d4fdeba7>] mmcrescan+0x54a/0x640 [mmc_core]

unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloctrace+0x21/0x110 [<00000000fcbe706c>] sdioallocfunc+0x35/0x100 [mmccore] [<00000000c68f4b50>] mmcattachsdio.cold.18+0xb1/0x395 [mmccore] [<00000000d4fdeba7>] mmcrescan+0x54a/0x640 mmc_core

In the Linux kernel through 6.7.1, there is a use-after-free in cecqueuemsg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.(CVE-2024-23848)

In the Linux kernel, the following vulnerability has been resolved:

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQDMOVEPCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.

When the interrupt next triggers on the original CPU, the new affinity is enforced within _irqmoveirq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->movein_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU, irqcompletemove() adds a task to the old CPU's vectorcleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vectorcleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.

In that case irqforcecompletemove() is not invoked on the outgoing CPU to reclaim the old apicd->prevvector because the interrupt isn't currently affine to the outgoing CPU, and irqneedsfixup() returns false. Even though _vectorschedulecleanup() is later called on the new CPU, it doesn't reclaim apicd->prevvector; instead, it simply resets both apicd->moveinprogress and apicd->prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.

To address this issue, move the invocation of irqforcecompletemove() before the irqneedsfixup() call to reclaim apicd->prevvector, if the interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in _vectorschedulecleanup() as well, following a warning message, although theoretically it should never see apicd->moveinprogress with apicd->prevcpu pointing to an offline CPU.(CVE-2024-31076)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_skbmod: prevent kernel-infoleak

syzbot found that tcfskbmoddump() was copying four bytes from kernel stack to user space [1].

The issue here is that 'struct tc_skbmod' has a four bytes hole.

We need to clear the structure before filling fields.

[1] BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copytoiter+0x366/0x2520 lib/ioviter.c:185 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] _copytoiter+0x366/0x2520 lib/ioviter.c:185 copytoiter include/linux/uio.h:196 [inline] simplecopytoiter net/core/datagram.c:532 [inline] _skbdatagramiter+0x185/0x1000 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:4050 [inline] netlinkrecvmsg+0x432/0x1610 net/netlink/afnetlink.c:1962 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x2c4/0x340 net/socket.c:1068 _sysrecvfrom+0x35a/0x5f0 net/socket.c:2242 _dosysrecvfrom net/socket.c:2260 [inline] _sesysrecvfrom net/socket.c:2256 [inline] _x64sysrecvfrom+0x126/0x1d0 net/socket.c:2256 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was stored to memory at: pskbexpandhead+0x30f/0x19d0 net/core/skbuff.c:2253 netlinktrim+0x2c2/0x330 net/netlink/afnetlink.c:1317 netlinkunicast+0x9f/0x1260 net/netlink/afnetlink.c:1351 nlmsgunicast include/net/netlink.h:1144 [inline] nlmsgnotify+0x21d/0x2f0 net/netlink/afnetlink.c:2610 rtnetlinksend+0x73/0x90 net/core/rtnetlink.c:741 rtnetlinkmaybesend include/linux/rtnetlink.h:17 [inline] tcfaddnotify net/sched/actapi.c:2048 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x146e/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2559 rtnetlinkrcv+0x34/0x40 net/core/rtnetlink.c:6613 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xf4c/0x1260 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10df/0x11f0 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x30f/0x380 net/socket.c:745 _syssendmsg+0x877/0xb60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x4a0 net/socket.c:2674 dosyscall64+0xd5/0x1f0 entrySYSCALL64after_hwframe+0x6d/0x75

Uninit was stored to memory at: _nlaput lib/nlattr.c:1041 [inline] nlaput+0x1c6/0x230 lib/nlattr.c:1099 tcfskbmoddump+0x23f/0xc20 net/sched/actskbmod.c:256 tcfactiondumpold net/sched/actapi.c:1191 [inline] tcfactiondump1+0x85e/0x970 net/sched/actapi.c:1227 tcfactiondump+0x1fd/0x460 net/sched/actapi.c:1251 tcagetfill+0x519/0x7a0 net/sched/actapi.c:1628 tcfaddnotifymsg net/sched/actapi.c:2023 [inline] tcfaddnotify net/sched/actapi.c:2042 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x1365/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetli ---truncated---(CVE-2024-35893)

In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: Fix uninit-value in ncidevup and ncintfpacket

syzbot reported the following uninit-value access issue [1][2]:

ncirxwork() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.

This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)

In the Linux kernel, the following vulnerability has been resolved:

drm/arm/malidp: fix a possible null pointer dereference

In malidpmwconnectorreset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mwstate is checked before calling _drmatomichelperconnector_reset.(CVE-2024-36014)

In the Linux kernel, the following vulnerability has been resolved:

amd/amdkfd: sync all devices to wait all processes being evicted

If there are more than one device doing reset in parallel, the first device will call kfdsuspendall_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)

In the Linux kernel, the following vulnerability has been resolved:

tcp: Fix shift-out-of-bounds in dctcpupdatealpha().

In dctcpupdatealpha(), we use a module parameter dctcpshiftg as follows:

alpha -= minnotzero(alpha, alpha >> dctcpshiftg); ... deliveredce <<= (10 - dctcpshift_g);

It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcpshiftg:

memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);

Let's limit the max value of dctcpshiftg by paramsetuint_minmax().

With this patch:

# echo 10 > /sys/module/tcpdctcp/parameters/dctcpshiftg # cat /sys/module/tcpdctcp/parameters/dctcpshiftg 10 # echo 11 > /sys/module/tcpdctcp/parameters/dctcpshift_g -bash: echo: write error: Invalid argument

shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:114 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleshiftoutofbounds+0x346/0x3a0 lib/ubsan.c:468 dctcpupdatealpha+0x540/0x570 net/ipv4/tcpdctcp.c:143 tcpinackevent net/ipv4/tcpinput.c:3802 [inline] tcpack+0x17b1/0x3bc0 net/ipv4/tcpinput.c:3948 tcprcvstateprocess+0x57a/0x2290 net/ipv4/tcpinput.c:6711 tcpv4dorcv+0x764/0xc40 net/ipv4/tcpipv4.c:1937 skbacklogrcv include/net/sock.h:1106 [inline] _releasesock+0x20f/0x350 net/core/sock.c:2983 releasesock+0x61/0x1f0 net/core/sock.c:3549 mptcpsubflowshutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcpchecksenddatafin+0x225/0x410 net/mptcp/protocol.c:2976 _mptcpclose+0x238/0xad0 net/mptcp/protocol.c:3072 mptcpclose+0x2a/0x1a0 net/mptcp/protocol.c:3127 inetrelease+0x190/0x1f0 net/ipv4/afinet.c:437 _sockrelease net/socket.c:659 [inline] sockclose+0xc0/0x240 net/socket.c:1421 _fput+0x41b/0x890 fs/filetable.c:422 taskworkrun+0x23b/0x300 kernel/taskwork.c:180 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x9c8/0x2540 kernel/exit.c:878 dogroupexit+0x201/0x2b0 kernel/exit.c:1027 _dosysexitgroup kernel/exit.c:1038 [inline] _sesysexitgroup kernel/exit.c:1036 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1036 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xe4/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)

In the Linux kernel, the following vulnerability has been resolved:

drm: vc4: Fix possible null pointer dereference

In vc4hdmiaudioinit() ofget_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)

In the Linux kernel, the following vulnerability has been resolved:

net: fec: remove .ndopollcontroller to avoid deadlocks

There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndopollcontroller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disableirq() is called by .ndopollcontroller interface of sungem driver, however, disableirq() might sleep. After analyzing the implementation of fecpollcontroller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndopollcontroller is unnecessary to be implemented in the fec driver, so fecpollcontroller() can be safely removed.(CVE-2024-38553)

In the Linux kernel, the following vulnerability has been resolved:

ax25: Fix reference count leak issue of net_device

There is a reference count leak issue of the object "netdevice" in ax25devdevicedown(). When the ax25 device is shutting down, the ax25devdevicedown() drops the reference count of netdevice one or zero times depending on if we goto unlock_put or not, which will cause memory leak.

In order to solve the above issue, decrease the reference count of netdevice after dev->ax25ptr is set to null.(CVE-2024-38554)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Ensure the copied buf is NUL terminated

Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdupusernul instead of memdup_user.(CVE-2024-38559)

In the Linux kernel, the following vulnerability has been resolved:

ecryptfs: Fix buffer size for tag 66 packet

The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and writetag66_packet() will write up to 3 bytes past the end of the buffer.

Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer.

This fixes the below kasan slab-out-of-bounds bug:

BUG: KASAN: slab-out-of-bounds in ecryptfsgeneratekeypacketset+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181

CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x4c/0x70 printreport+0xc5/0x610 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 ? kasancompletemodereportinfo+0x44/0x210 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 kasanreport+0xc2/0x110 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 asanstore1+0x62/0x80 ecryptfsgeneratekeypacketset+0x7d6/0xde0 ? _pfxecryptfsgeneratekeypacketset+0x10/0x10 ? _allocpages+0x2e2/0x540 ? _pfxovlopen+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentryopen+0x8f/0xd0 ecryptfswritemetadata+0x30a/0x550 ? _pfxecryptfswritemetadata+0x10/0x10 ? ecryptfsgetlowerfile+0x6b/0x190 ecryptfsinitializefile+0x77/0x150 ecryptfscreate+0x1c2/0x2f0 pathopenat+0x17cf/0x1ba0 ? _pfxpathopenat+0x10/0x10 dofilpopen+0x15e/0x290 ? _pfxdofilpopen+0x10/0x10 ? _kasancheckwrite+0x18/0x30 ? rawspinlock+0x86/0xf0 ? _pfxrawspinlock+0x10/0x10 ? kasancheckwrite+0x18/0x30 ? allocfd+0xf4/0x330 dosysopenat2+0x122/0x160 ? _pfxdosysopenat2+0x10/0x10 _x64sysopenat+0xef/0x170 ? _pfxx64sysopenat+0x10/0x10 dosyscall64+0x60/0xd0 entrySYSCALL64afterhwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK>

Allocated by task 181: kasansavestack+0x2f/0x60 kasansettrack+0x29/0x40 kasansaveallocinfo+0x25/0x40 _kasankmalloc+0xc5/0xd0 _kmalloc+0x66/0x160 ecryptfsgeneratekeypacketset+0x6d2/0xde0 ecryptfswritemetadata+0x30a/0x550 ecryptfsinitializefile+0x77/0x150 ecryptfscreate+0x1c2/0x2f0 pathopenat+0x17cf/0x1ba0 dofilpopen+0x15e/0x290 dosysopenat2+0x122/0x160 _x64sysopenat+0xef/0x170 dosyscall64+0x60/0xd0 entrySYSCALL64after_hwframe+0x6e/0xd8(CVE-2024-38578)

In the Linux kernel, the following vulnerability has been resolved:

crypto: bcm - Fix pointer arithmetic

In spu2dumpomd() value of ptr is increased by ciphkeylen instead of hashivlen which could lead to going beyond the buffer boundaries. Fix this bug by changing ciphkeylen to hashivlen.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential hang in nilfsdetachlog_writer()

Syzbot has reported a potential hang in nilfsdetachlog_writer() called during nilfs2 unmount.

Analysis revealed that this is because nilfssegctorsync(), which synchronizes with the log writer thread, can be called after nilfssegctordestroy() terminates that thread, as shown in the call trace below:

nilfsdetachlogwriter nilfssegctordestroy nilfssegctorkillthread --> Shut down log writer thread flushwork nilfsiputworkfunc nilfsdisposelist iput nilfsevictinode nilfstransactioncommit nilfsconstructsegment (if inode needs sync) nilfssegctorsync --> Attempt to synchronize with log writer thread * DEADLOCK *

Fix this issue by changing nilfssegctorsync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.

The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfssegctordestroy().(CVE-2024-38582)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix use-after-free of timer for log writer thread

Patch series "nilfs2: fix log writer related issues".

This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.

This patch (of 3):

A use-after-free issue has been reported regarding the timer sctimer on the nilfssc_info structure.

The problem is that even though it is used to wake up a sleeping log writer thread, sctimer is not shut down until the nilfssc_info structure is about to be freed, and is used regardless of the thread's lifetime.

Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.(CVE-2024-38583)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: timer: Set lower bound of start tick time

Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer.

This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.(CVE-2024-38618)

In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Update uartdriverregistered on driver removal

The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses:

max3100 spi-PRP0001:01: max3100probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serialcoreregisterport+0xa0/0x840 ... max3100probe+0x1b6/0x280 [max3100] spiprobe+0x8d/0xb0

Update the actual state so next time UART driver will be registered again.

Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uartregisterdriver() call.(CVE-2024-38633)

In the Linux kernel, the following vulnerability has been resolved:

serial: max3100: Lock port->lock when calling uarthandlects_change()

uarthandlects_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:

WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serialcore.c:3491 uarthandlectschange+0xa6/0xb0 ... Workqueue: max3100-0 max3100work [max3100] RIP: 0010:uarthandlectschange+0xa6/0xb0 ... max3100handlerx+0xc5/0x110 [max3100] max3100work+0x12a/0x340 max3100

In the Linux kernel, the following vulnerability has been resolved:

greybus: lights: check return of getchannelfrom_mode

If channel for the given node is not found we return null from getchannelfrom_mode. Make sure we validate the return pointer before using it in two of the missing places.

This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE.

[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)

In the Linux kernel, the following vulnerability has been resolved:

enic: Validate length of nl attributes in enicsetvf_port

enicsetvfport assumes that the nl attribute IFLAPORTPROFILE is of length PORTPROFILEMAX and that the nl attributes IFLAPORTINSTANCEUUID, IFLAPORTHOSTUUID are of length PORTUUIDMAX. These attributes are validated (in the function dosetlink in rtnetlink.c) using the nlapolicy iflaportpolicy. The policy defines IFLAPORTPROFILE as NLASTRING, IFLAPORTINSTANCEUUID as NLABINARY and IFLAPORTHOSTUUID as NLASTRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enicsetvfport expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enicsetvfport.(CVE-2024-38659)

In the Linux kernel, the following vulnerability has been resolved:

dma-buf/sw-sync: don't enable IRQ from syncprintobj()

Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spinunlockirqrestore() with spinunlockirq() for both syncdebugfsshow() and syncprintobj() despite syncprintobj() is called from syncdebugfsshow(), lockdep complains inconsistent lock state warning.

Use plain spin{lock,unlock}() for syncprintobj(), for syncdebugfsshow() is already using spin{lock,unlock}_irq().(CVE-2024-38780)

In the Linux kernel, the following vulnerability has been resolved:

net/9p: fix uninit-value in p9clientrpc()

Syzbot with the help of KMSAN reported the following error:

BUG: KMSAN: uninit-value in trace9pclientres include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9clientrpc+0x1314/0x1340 net/9p/client.c:754 trace9pclientres include/trace/events/9p.h:146 [inline] p9clientrpc+0x1314/0x1340 net/9p/client.c:754 p9clientcreate+0x1551/0x1ff0 net/9p/client.c:1031 v9fssessioninit+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fsmount+0xe2/0x12b0 fs/9p/vfssuper.c:122 legacygettree+0x114/0x290 fs/fscontext.c:662 vfsgettree+0xa7/0x570 fs/super.c:1797 donewmount+0x71f/0x15e0 fs/namespace.c:3352 pathmount+0x742/0x1f20 fs/namespace.c:3679 domount fs/namespace.c:3692 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x725/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x150 fs/namespace.c:3875 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: allocpages+0x9d6/0xe70 mm/pagealloc.c:4598 _allocpagesnode include/linux/gfp.h:238 [inline] allocpagesnode include/linux/gfp.h:261 [inline] allocslabpage mm/slub.c:2175 [inline] allocateslab mm/slub.c:2338 [inline] newslab+0x2de/0x1400 mm/slub.c:2391 _slaballoc+0x1184/0x33d0 mm/slub.c:3525 _slaballoc mm/slub.c:3610 [inline] _slaballocnode mm/slub.c:3663 [inline] slaballocnode mm/slub.c:3835 [inline] kmemcachealloc+0x6d3/0xbe0 mm/slub.c:3852 p9tagalloc net/9p/client.c:278 [inline] p9clientpreparereq+0x20a/0x1770 net/9p/client.c:641 p9clientrpc+0x27e/0x1340 net/9p/client.c:688 p9clientcreate+0x1551/0x1ff0 net/9p/client.c:1031 v9fssessioninit+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fsmount+0xe2/0x12b0 fs/9p/vfssuper.c:122 legacygettree+0x114/0x290 fs/fscontext.c:662 vfsgettree+0xa7/0x570 fs/super.c:1797 donewmount+0x71f/0x15e0 fs/namespace.c:3352 pathmount+0x742/0x1f20 fs/namespace.c:3679 domount fs/namespace.c:3692 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x725/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x150 fs/namespace.c:3875 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

If p9checkerrors() fails early in p9clientrpc(), req->rc.tag will not be properly initialized. However, trace9pclientres() ends up trying to print it out anyway before p9client_rpc() finishes.

Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.(CVE-2024-39301)