The Linux Kernel, the operating system core itself.

Security Fix(es):

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

firmware: arm_scmi: Harden accesses to the reset domains

Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.

Add an internal consistency check before any such domains descriptors accesses.(CVE-2022-48655)

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

erofs: fix pcluster use-after-free on UP platforms

During stress testing with CONFIG_SMP disabled, KASAN reports as below:

================================================================== BUG: KASAN: use-after-free in _mutexlock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789

CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. _mutexlock+0xe5/0xc30 .. zerofsdoreadpage+0x8ce/0x1560 .. zerofsreadahead+0x31c/0x580 .. Freed by task 7787 kasansavestack+0x1e/0x40 kasansettrack+0x20/0x30 kasansetfreeinfo+0x20/0x40 _kasanslabfree+0x10c/0x190 kmemcachefree+0xed/0x380 rcucore+0x3d5/0xc90 _do_softirq+0x12d/0x389

Last potentially related work creation: kasansavestack+0x1e/0x40 _kasanrecordauxstack+0x97/0xb0 callrcu+0x3d/0x3f0 erofsshrinkworkstation+0x11f/0x210 erofsshrinkscan+0xdc/0x170 shrinkslab.constprop.0+0x296/0x530 dropslab+0x1c/0x70 dropcachessysctlhandler+0x70/0x80 procsyscallhandler+0x20a/0x2f0 vfswrite+0x555/0x6c0 ksyswrite+0xbe/0x160 dosyscall_64+0x3b/0x90

The root cause is that erofsworkgroupunfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing.

Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead.(CVE-2022-48674)

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

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usbgetbos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS GoogleKindred.12672.413.0 02/03/2021 Workqueue: usbhubwq hubevent RIP: 0010:hubportreset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hubevent+0x73f/0x156e ? hubactivate+0x5b7/0x68f processonework+0x1a2/0x487 workerthread+0x11a/0x288 kthread+0x13a/0x152 ? processonework+0x487/0x487 ? kthreadassociateblkcg+0x70/0x70 retfrom_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)

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

netfilter: nf_tables: disallow timeout for anonymous sets

Never used from userspace, disallow these parameters.(CVE-2023-52620)

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

netfilter: nftables: exthdr: fix 4-byte stack OOB write

If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption.

This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does.

The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added.

Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)

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

fs/ntfs3: Fix an NULL dereference bug

The issue here is when this is called from ntfsloadattrlist(). The "size" comes from le32tocpu(attr->res.datasize) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZEROSIZEPTR and then the memcpy() will crash with an Oops on the next line.(CVE-2023-52631)

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

um: time-travel: fix time corruption

In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding.

Fix this by reading the timetraveltime, calculating the adjustment, and doing the adjustment all with interrupts disabled.(CVE-2023-52633)

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

can: j1939: Fix UAF in j1939skmatchfilter during setsockopt(SOJ1939_FILTER)

Lock jsk->sk to prevent UAF when setsockopt(..., SOJ1939FILTER, ...) modifies jsk->filters while receiving packets.

Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939skrecvmatchone+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350

CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: printreport+0xd3/0x620 ? kasancompletemodereportinfo+0x7d/0x200 ? j1939skrecvmatchone+0x1af/0x2d0 [canj1939] kasanreport+0xc2/0x100 ? j1939skrecvmatchone+0x1af/0x2d0 [canj1939] asanload4+0x84/0xb0 j1939skrecvmatchone+0x1af/0x2d0 [canj1939] j1939skrecv+0x20b/0x320 [canj1939] ? _kasancheckwrite+0x18/0x20 ? _pfxj1939skrecv+0x10/0x10 [canj1939] ? j1939simplerecv+0x69/0x280 [canj1939] ? j1939acrecv+0x5e/0x310 [canj1939] j1939canrecv+0x43f/0x580 [canj1939] ? _pfxj1939canrecv+0x10/0x10 [canj1939] ? rawrcv+0x42/0x3c0 [canraw] ? _pfxj1939canrecv+0x10/0x10 [canj1939] canrcvfilter+0x11f/0x350 [can] canreceive+0x12f/0x190 [can] ? _pfxcanrcv+0x10/0x10 [can] canrcv+0xdd/0x130 [can] ? _pfxcanrcv+0x10/0x10 [can] _netifreceiveskbonecore+0x13d/0x150 ? _pfxnetifreceiveskbonecore+0x10/0x10 ? kasancheckwrite+0x18/0x20 ? _rawspinlockirq+0x8c/0xe0 _netifreceiveskb+0x23/0xb0 processbacklog+0x107/0x260 _napipoll+0x69/0x310 netrxaction+0x2a1/0x580 ? _pfxnetrxaction+0x10/0x10 ? _pfxrawspinlock+0x10/0x10 ? handleirqevent+0x7d/0xa0 _dosoftirq+0xf3/0x3f8 dosoftirq+0x53/0x80 </IRQ> <TASK> _localbhenableip+0x6e/0x70 netifrx+0x16b/0x180 cansend+0x32b/0x520 [can] ? _pfxcansend+0x10/0x10 [can] ? _checkobjectsize+0x299/0x410 rawsendmsg+0x572/0x6d0 [canraw] ? _pfxrawsendmsg+0x10/0x10 [canraw] ? apparmorsocketsendmsg+0x2f/0x40 ? _pfxrawsendmsg+0x10/0x10 [canraw] socksendmsg+0xef/0x100 sockwriteiter+0x162/0x220 ? _pfxsockwriteiter+0x10/0x10 ? _rtnlunlock+0x47/0x80 ? securityfilepermission+0x54/0x320 vfswrite+0x6ba/0x750 ? _pfxvfswrite+0x10/0x10 ? _fgetlight+0x1ca/0x1f0 ? _rcureadunlock+0x5b/0x280 ksyswrite+0x143/0x170 ? _pfxksyswrite+0x10/0x10 ? _kasancheckread+0x15/0x20 ? fpregsassertstateconsistent+0x62/0x70 _x64syswrite+0x47/0x60 dosyscall64+0x60/0x90 ? dosyscall64+0x6d/0x90 ? irqentryexit+0x3f/0x50 ? excpagefault+0x79/0xf0 entrySYSCALL64afterhwframe+0x6e/0xd8

Allocated by task 348: kasansavestack+0x2a/0x50 kasansettrack+0x29/0x40 kasansaveallocinfo+0x1f/0x30 _kasankmalloc+0xb5/0xc0 _kmallocnodetrackcaller+0x67/0x160 j1939sksetsockopt+0x284/0x450 [canj1939] _syssetsockopt+0x15c/0x2f0 _x64syssetsockopt+0x6b/0x80 dosyscall64+0x60/0x90 entrySYSCALL64after_hwframe+0x6e/0xd8

Freed by task 349: kasansavestack+0x2a/0x50 kasansettrack+0x29/0x40 kasansavefreeinfo+0x2f/0x50 _kasanslabfree+0x12e/0x1c0 _kmemcachefree+0x1b9/0x380 kfree+0x7a/0x120 j1939sksetsockopt+0x3b2/0x450 [canj1939] _syssetsockopt+0x15c/0x2f0 _x64syssetsockopt+0x6b/0x80 dosyscall64+0x60/0x90 entrySYSCALL64after_hwframe+0x6e/0xd8(CVE-2023-52637)

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

KVM: s390: vsie: fix race during shadow creation

Right now it is possible to see gmap->private being zero in kvms390vsiegmapnotifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation:

static int acquiregmapshadow(struct kvmvcpu *vcpu, struct vsiepage *vsiepage) { [...] gmap = gmapshadow(vcpu->arch.gmap, asce, edat); if (ISERR(gmap)) return PTRERR(gmap); gmap->private = vcpu->kvm;

Let children inherit the private field of the parent.(CVE-2023-52639)

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

media: rc: bpf attach/detach requires write permission

Note that bpf attach/detach also requires CAPNETADMIN.(CVE-2023-52642)

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

wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated.

Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 ieee80211wakequeue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) sndseqdummy sndhrtimer sndseq sndseqdevice nftchainnat xtMASQUERADE nfnat xfrmuser xfrmalgo xtaddrtype overlay ccm afpacket amdgpu sndhdacodeccirrus sndhdacodecgeneric ledtrigaudio drmexec amdxcp gpusched xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 ip6trpfilter iptrpfilter xtpkttype xtLOG nflogsyslog xttcpudp nftcompat nftables nfnetlink schfqcodel btusb uinput iTCOwdt ctr btrtl intelpmcbxt i915 intelraplmsr meihdcp meipxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldifmap btmtk intelraplcommon sndhdacodechdmi bluetooth uvcvideo nlsiso88591 applesmc nlscp437 x86pkgtempthermal sndhdaintel intelpowerclamp vfat videobuf2vmalloc coretemp fat sndinteldspcfg crc32pclmul uvc polyvalclmulni sndintelsdwacpi loop videobuf2memops sndhdacodec tun drmsuballochelper polyvalgeneric drmttmhelper drmbuddy tap ecdhgeneric videobuf2v4l2 gf128mul macvlan ttm ghashclmulniintel ecc tg3 [ +0.000044] videodev bridge sndhdacore rapl crc16 drmdisplayhelper cec mousedev sndhwdep evdev intelcstate bcm5974 hidappleir videobuf2common stp machid libphy sndpcm drmkmshelper acpials meime inteluncore llc mc sndtimer intelgtt industrialiotriggeredbuffer applemfifastcharge i2ci801 mei snd lpcich agpgart ptp i2csmbus thunderbolt applegmux i2calgobit kfifobuf video industrialio soundcore ppscore wmi tinypowerbutton sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvmintel kvm drm irqbypass fuse backlight firmwareclass efipstore configfs efivarfs dmisysfs iptables xtables autofs4 dmcrypt cbc encryptedkeys trusted asn1encoder tee tpm rngcore inputleds hidapple ledclass hidgeneric usbhid hid sdmod t10pi crc64rocksoft crc64 crct10dif crct10difgeneric ahci libahci libata uhcihcd ehcipci ehcihcd crct10difpclmul crct10difcommon sha512ssse3 sha512generic sha256ssse3 sha1ssse3 aesniintel usbcore scsimod libaes cryptosimd cryptd scsicommon [ +0.000055] usbcommon rtccmos btrfs blake2bgeneric libcrc32c crc32cgeneric crc32cintel xor raid6pq dmsnapshot dmbufio dmmod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:ieee80211wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---(CVE-2023-52644)

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)

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

netfilter: nf_tables: disallow anonymous set with timeout flag

Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFTSETEVAL to ensure legacy meters still work.(CVE-2024-26642)

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

tracing: Ensure visibility when inserting an element into tracing_map

Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:

$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)

The warning looks as follows:

[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] _arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---

The problem appears to be caused by CPU reordering of writes issued from _tracingmap_insert().

The check for the presence of an element with a given key in this function is:

val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->key_size)) ...

The write of a new entry is:

elt = getfreeelt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;

The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---(CVE-2024-26645)

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

tunnels: fix out of bounds access when building IPv6 PMTU error

If the ICMPv6 error is built from a non-linear skb we get the following splat,

BUG: KASAN: slab-out-of-bounds in docsum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasanreport+0xd8/0x110 docsum+0x220/0x240 csumpartial+0xc/0x20 skbtunnelcheckpmtu+0xeb9/0x3280 vxlanxmitone+0x14c2/0x4080 vxlanxmit+0xf61/0x5c00 devhardstartxmit+0xfb/0x510 _devqueuexmit+0x7cd/0x32a0 brdevqueuepushxmit+0x39d/0x6a0

Use skbchecksum instead of csumpartial who cannot deal with non-linear SKBs.(CVE-2024-26665)

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

netfilter: nft_limit: reject configurations that cause integer overflow

Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s.

Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)

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

net/sched: flower: Fix chain template offload

When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOWBLOCKUNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOWCLSDESTROY' command for each filter.

However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOWCLSTMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2].

Fix by introducing a 'tmpltreoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOWCLSTMPLT{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one.

As far as I can tell, the issue happens since cited commit which reordered tcfblockoffloadunbind() before tcfblockflushallchains() in _tcfblockput(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains.

[1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [<ffffffff81c06a68>] kmemcacheallocnode+0x1e8/0x320 [<ffffffff81ab374e>] _kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxswspaclrulesetget+0x34d/0x7a0 [<ffffffff832bc195>] mlxswspflowertmpltcreate+0x145/0x180 [<ffffffff832b2e1a>] mlxswspflowblockcb+0x1ea/0x280 [<ffffffff83a10613>] tcsetupcbcall+0x183/0x340 [<ffffffff83a9f85a>] fltmpltcreate+0x3da/0x4c0 [<ffffffff83a22435>] tcctlchain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlinkrcvmsg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlinkrcvskb+0x170/0x440 [<ffffffff83ac6270>] netlinkunicast+0x540/0x820 [<ffffffff83ac6e28>] netlinksendmsg+0x8d8/0xda0 [<ffffffff83793def>] _syssendmsg+0x30f/0xa80 [<ffffffff8379d29a>] syssendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] _syssendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] dosyscall64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [<ffffffff81c06a68>] _kmemcacheallocnode+0x1e8/0x320 [<ffffffff81ab36c1>] _kmallocnode+0x51/0x90 [<ffffffff81a8ed96>] kvmallocnode+0xa6/0x1f0 [<ffffffff82827d03>] buckettablealloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtableinit+0x43b/0x7c0 [<ffffffff832aed48>] mlxswspaclrulesetget+0x428/0x7a0 [<ffffffff832bc195>] mlxswspflowertmpltcreate+0x145/0x180 [<ffffffff832b2e1a>] mlxswspflowblockcb+0x1ea/0x280 [<ffffffff83a10613>] tcsetupcbcall+0x183/0x340 [<ffffffff83a9f85a>] fltmpltcreate+0x3da/0x4c0 [<ffffffff83a22435>] tcctlchain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlinkrcvmsg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlinkrcvskb+0x170/0x440 [<ffffffff83ac6270>] netlinkunicast+0x540/0x820 [<ffffffff83ac6e28>] netlinksendmsg+0x8d8/0xda0 [<ffffffff83793def>] sys_sendmsg+0x30f/0xa80

[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated---(CVE-2024-26669)

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

blk-mq: fix IO hang from sbitmap wakeup race

In blkmqmarktagwait(), _addwaitqueue() may be re-ordered with the following blkmqgetdriver_tag() in case of getting driver tag failure.

Then in _sbitmapqueuewakeup(), waitqueueactive() may not observe the added waiter in blkmqmarktagwait() and wake up nothing, meantime blkmqmarktag_wait() can't get driver tag successfully.

This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop.

modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
        --runtime=100 --numjobs=40 --time_based --name=test \
        --ioengine=libaio

Fix the issue by adding one explicit barrier in blkmqmarktagwait(), which is just fine in case of running out of tag.(CVE-2024-26671)

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

inet: read sk->skfamily once in inetrecv_error()

inetrecverror() is called without holding the socket lock.

IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.(CVE-2024-26679)

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

net: atlantic: Fix DMA mapping for PTP hwts ring

Function aqringhwtsrxalloc() maps extra AQCFGRXDSDEF bytes for PTP HWTS ring but then generic aqring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue.

Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 checkunmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? showtraceloglvl+0x1c4/0x2df [ 215.590114] ? showtraceloglvl+0x1c4/0x2df [ 215.594497] ? debugdmafreecoherent+0x196/0x210 [ 215.599305] ? checkunmap+0xa6f/0x2360 [ 215.603147] ? _warn+0xca/0x1d0 [ 215.606391] ? checkunmap+0xa6f/0x2360 [ 215.610237] ? reportbug+0x1ef/0x370 [ 215.613921] ? handlebug+0x3c/0x70 [ 215.617423] ? excinvalidop+0x14/0x50 [ 215.621269] ? asmexcinvalidop+0x16/0x20 [ 215.625480] ? checkunmap+0xa6f/0x2360 [ 215.629331] ? marklock.part.0+0xca/0xa40 [ 215.633445] debugdmafreecoherent+0x196/0x210 [ 215.638079] ? _pfxdebugdmafreecoherent+0x10/0x10 [ 215.643242] ? slabfreefreelisthook+0x11d/0x1d0 [ 215.648060] dmafreeattrs+0x6d/0x130 [ 215.651834] aqringfree+0x193/0x290 [atlantic] [ 215.656487] aqptpringfree+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debugdmaalloccoherent+0x66/0x2f0 [ 216.132165] dmaallocattrs+0xf5/0x1b0 [ 216.132168] aqringhwtsrxalloc+0x150/0x1f0 [atlantic] [ 216.132193] aqptpringalloc+0x1bb/0x540 [atlantic] [ 216.132213] aqnicinit+0x4a1/0x760 atlantic

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

net: stmmac: xgmac: fix handling of DPP safety error for DMA channels

Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMADPPInterrupt_Status register.(CVE-2024-26684)

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

nilfs2: fix potential bug in endbufferasync_write

According to a syzbot report, endbufferasyncwrite(), which handles the completion of block device writes, may detect abnormal condition of the buffer asyncwrite flag and cause a BUG_ON failure when using nilfs2.

Nilfs2 itself does not use endbufferasyncwrite(). But, the asyncwrite flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfslookupdirtydatabuffers() and nilfslookupnode_buffers() and the resulting crash.

This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce asyncwrite for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUGON check in endbufferasync_write would fail as described above, if independent writebacks of the backing device occurred in parallel.

The use of async_write for segment summary buffers has already been removed in a previous change.

Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.(CVE-2024-26685)

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

fs,hugetlb: fix NULL pointer dereference in hugetlbsfillsuper

When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfsfillsuper() caused by assigning NULL to ctx->hstate in hugetlbfsparseparam() when the requested pagesize is non valid.

E.g: Taking the following steps:

 fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
 fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
 fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);

Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error:

... ... case Optpagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { prerr("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ...

This is a problem because later on, we will dereference ctxt->hstate in hugetlbfsfillsuper()

... ... sb->sblocksize = hugepage_size(ctx->hstate); ... ...

Causing below Oops.

Fix this by replacing cxt->hstate value only when then pagesize is known to be valid.

kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: errorcode(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfsfillsuper+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: <TASK> kernel: ? _diebody+0x1a/0x60 kernel: ? pagefaultoops+0x16f/0x4a0 kernel: ? searchbpfextables+0x65/0x70 kernel: ? fixupexception+0x22/0x310 kernel: ? excpagefault+0x69/0x150 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? _pfxhugetlbfsfillsuper+0x10/0x10 kernel: ? hugetlbfsfillsuper+0xb4/0x1a0 kernel: ? hugetlbfsfillsuper+0x28/0x1a0 kernel: ? _pfxhugetlbfsfillsuper+0x10/0x10 kernel: vfsgetsuper+0x40/0xa0 kernel: ? _pfxbpflsmcapable+0x10/0x10 kernel: vfsgettree+0x25/0xd0 kernel: vfscmdcreate+0x64/0xe0 kernel: _x64sysfsconfig+0x395/0x410 kernel: dosyscall64+0x80/0x160 kernel: ? syscallexittousermode+0x82/0x240 kernel: ? dosyscall64+0x8d/0x160 kernel: ? syscallexittousermode+0x82/0x240 kernel: ? dosyscall64+0x8d/0x160 kernel: ? excpagefault+0x69/0x150 kernel: entrySYSCALL64afterhwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated---(CVE-2024-26688)

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

ceph: prevent use-after-free in encodecapmsg()

In fs/ceph/caps.c, in encodecapmsg(), "use after free" error was caught by KASAN at this line - 'cephbufferget(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed.

In same file, in "handlecapgrant()" refcount is decremented by this line - 'cephbufferput(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it.

encodecapmsg() is called by _sendcap() and _sendcap() is called by cephcheckcaps() after calling _prepcap(). _prepcap() is where arg->xattrbuf is assigned to ci->ixattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)

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

nilfs2: fix data corruption in dsync block recovery for small block sizes

The helper function nilfsrecoverycopyblock() of nilfsrecoverydsyncblocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process.

Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)

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

parisc: Fix random data corruption from exception handler

The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASMEXCEPTIONTABLEREG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd().

To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer.

This patch takes another, better and more flexible approach: We extend the _extable (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the _extable entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register.

Since we extend the _extable to 3 words we can't use the BUILDTIMETABLESORT config option any longer.(CVE-2024-26706)

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

net: hsr: remove WARNONCE() in sendhsrsupervisionframe()

Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsrinitskb(). Since a WARNONCE() call will not help much in this case, it might be prudent to switch to netdevwarn_once(). At the very least it will suppress syzkaller reports such as [1].

Just in case, use netdevwarnonce() in sendprpsupervision_frame() for similar reasons.

[1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsrdevice.c:294 sendhsrsupervisionframe+0x60a/0x810 net/hsr/hsrdevice.c:294 RIP: 0010:sendhsrsupervisionframe+0x60a/0x810 net/hsr/hsrdevice.c:294 ... Call Trace: <IRQ> hsrannounce+0x114/0x370 net/hsr/hsrdevice.c:382 calltimerfn+0x193/0x590 kernel/time/timer.c:1700 expiretimers kernel/time/timer.c:1751 [inline] _runtimers+0x764/0xb20 kernel/time/timer.c:2022 runtimersoftirq+0x58/0xd0 kernel/time/timer.c:2035 _dosoftirq+0x21a/0x8de kernel/softirq.c:553 invokesoftirq kernel/softirq.c:427 [inline] _irqexitrcu kernel/softirq.c:632 [inline] irqexitrcu+0xb7/0x120 kernel/softirq.c:644 sysvecapictimerinterrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asmsysvecapictimer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ...

This issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)

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

mm/writeback: fix possible divide-by-zero in wbdirtylimits(), again

(struct dirtythrottlecontrol *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated.

Use div64u64() instead of divu64() so that the value used in the "is this a safe division" check is the same as the divisor.

Also, remove redundant cast of the numerator to u64, as that should happen implicitly.

This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domaindritylimits() uses, but is much easier in global writeback domain with a BDICAPSTRICTLIMIT-backing device, using e.g. vm.dirtybytes=(1<<32)*PAGESIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)

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

btrfs: don't drop extent_map for free space inode on write error

While running the CI for an unrelated change I hit the following panic with generic/648 on btrfsholesspacecache.

assertion failed: blockstart != EXTENTMAPHOLE, in fs/btrfs/extentio.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extentio.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:extentwritepageio.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extentwritecachepages+0x2ac/0x8f0 extentwritepages+0x87/0x110 dowritepages+0xd5/0x1f0 filemapfdatawritewbc+0x63/0x90 _filemapfdatawriterange+0x5c/0x80 btrfsfdatawriterange+0x1f/0x50 btrfswriteoutcache+0x507/0x560 btrfswritedirtyblockgroups+0x32a/0x420 commitcowonlyroots+0x21b/0x290 btrfscommittransaction+0x813/0x1360 btrfssyncfile+0x51a/0x640 _x64sysfdatasync+0x52/0x90 dosyscall64+0x9c/0x190 entrySYSCALL64after_hwframe+0x6e/0x76

This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfsgetextent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENTMAPHOLE for the requested range.

This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map.

Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range.

I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.(CVE-2024-26726)

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

arp: Prevent overflow in arpreqget().

syzkaller reported an overflown write in arpreqget(). [0]

When ioctl(SIOCGARP) is issued, arpreqget() looks up an neighbour entry and copies neigh->ha to struct arpreq.arpha.sadata.

The arpha here is struct sockaddr, not struct sockaddrstorage, so the sa_data buffer is just 14 bytes.

In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem.

However, when dev->addrlen is greater than 22 (e.g. MAXADDRLEN), arpnetmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arpioctl() before calling arpreq_get().

To avoid the overflow, let's limit the max length of memcpy().

Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller.

WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arpioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inetioctl+0x314/0x3a0 net/ipv4/afinet.c:981 sockdoioctl+0xdf/0x260 net/socket.c:1204 sockioctl+0x3ef/0x650 net/socket.c:1321 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x18e/0x220 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x37/0x90 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK>(CVE-2024-26733)

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

devlink: fix possible use-after-free and memory leaks in devlink_init()

The pernet operations structure for the subsystem must be registered before registering the generic netlink family.

Make an unregister in case of unsuccessful registration.(CVE-2024-26734)

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

ipv6: sr: fix possible use-after-free and null-ptr-deref

The pernet operations structure for the subsystem must be registered before registering the generic netlink family.(CVE-2024-26735)

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

net/sched: act_mirred: don't override retval if we already lost the skb

If we're redirecting the skb, and haven't called tcfmirredforward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcfmirredforward(), however, the skb is out of our hands and returning SHOT will lead to UaF.

Move the retval override to the error path which actually need it.(CVE-2024-26739)

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

net/sched: act_mirred: use the backlog for mirred ingress

The test Davide added in commit ca22da2fbd69 ("actmirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcpv4rcv -> tcpv4_rcv deadlock reported by lockdep.

The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls.

In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.(CVE-2024-26740)

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

RDMA/qedr: Fix qedrcreateuser_qp error flow

Avoid the following warning by making sure to free the allocated resources in case that qedrinituser_queue() fail.

-----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdmacore.c:874 uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] Modules linked in: tls targetcoreuser uio targetcorepscsi targetcorefile targetcoreiblock ibsrpt ibsrp scsitransportsrp nfsd nfsacl rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opavnic ibumad ibipoib sunrpc rdmaucm ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm hfi1 intelraplmsr intelraplcommon mgag200 qedr sbedac drmshmemhelper rdmavt x86pkgtempthermal drmkmshelper intelpowerclamp ibuverbs coretemp i2calgobit kvmintel dellwmidescriptor ipmissif sparsekeymap kvm ibcore rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmisi ipmidevintf fbsysfops rapl iTCOwdt mxmwmi iTCOvendorsupport intelcstate pcspkr dcdbas inteluncore ipmimsghandler lpcich acpipowermeter meime mei fuse drm xfs libcrc32c qede sdmod ahci libahci t10pi sg crct10difpclmul crc32pclmul crc32cintel qed libata tg3 ghashclmulniintel megaraidsas crc8 wmi [last unloaded: ibsrpt] CPU: 0 PID: 143192 Comm: firdmtaggedp Kdump: loaded Not tainted 5.14.0-408.el9.x8664 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? ibuverbsclose+0x1f/0xb0 [ibuverbs] ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ? _warn+0x81/0x110 ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ? reportbug+0x10a/0x140 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ibuverbsclose+0x1f/0xb0 [ibuverbs] _fput+0x94/0x250 taskworkrun+0x5c/0x90 doexit+0x270/0x4a0 dogroupexit+0x2d/0x90 getsignal+0x87c/0x8c0 archdosignalorrestart+0x25/0x100 ? ibuverbsioctl+0xc2/0x110 [ibuverbs] exittousermodeloop+0x9c/0x130 exittousermodeprepare+0xb6/0x100 syscallexittousermode+0x12/0x40 dosyscall64+0x69/0x90 ? syscallexitwork+0x103/0x130 ? syscallexittousermode+0x22/0x40 ? dosyscall64+0x69/0x90 ? syscallexitwork+0x103/0x130 ? syscallexittousermode+0x22/0x40 ? dosyscall64+0x69/0x90 ? dosyscall64+0x69/0x90 ? commoninterrupt+0x43/0xa0 entrySYSCALL64afterhwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)

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

RDMA/srpt: Support specifying the srptserviceguid parameter

Make loading ibsrpt with this parameter set work. The current behavior is that setting that parameter while loading the ibsrpt kernel module triggers the following kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parseone+0x18c/0x1d0 parseargs+0xe1/0x230 loadmodule+0x8de/0xa60 initmodulefromfile+0x8b/0xd0 idempotentinitmodule+0x181/0x240 _x64sysfinitmodule+0x5a/0xb0 dosyscall64+0x5f/0xe0 entrySYSCALL64afterhwframe+0x6e/0x76(CVE-2024-26744)

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

gtp: fix use-after-free and null-ptr-deref in gtpgenldump_pdp()

The gtpnetops pernet operations structure for the subsystem must be registered before registering the generic netlink family.

Syzkaller hit 'general protection fault in gtpgenldump_pdp' bug:

general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtpgenldumppdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? showregs+0x90/0xa0 ? dieaddr+0x50/0xd0 ? excgeneralprotection+0x148/0x220 ? asmexcgeneralprotection+0x22/0x30 ? gtpgenldumppdp+0x1be/0x800 [gtp] ? allocskb+0x1dd/0x350 ? _pfxallocskb+0x10/0x10 genldumpit+0x11d/0x230 netlinkdump+0x5b9/0xce0 ? lockdephardirqsonprepare+0x253/0x430 ? _pfxnetlinkdump+0x10/0x10 ? kasansavetrack+0x10/0x40 ? _kasankmalloc+0x9b/0xa0 ? genlstart+0x675/0x970 _netlinkdumpstart+0x6fc/0x9f0 genlfamilyrcvmsgdumpit+0x1bb/0x2d0 ? _pfxgenlfamilyrcvmsgdumpit+0x10/0x10 ? genlopfromsmall+0x2a/0x440 ? capcapable+0x1d0/0x240 ? _pfxgenlstart+0x10/0x10 ? _pfxgenldumpit+0x10/0x10 ? _pfxgenldone+0x10/0x10 ? security_capable+0x9d/0xe0(CVE-2024-26754)

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

dm-crypt: don't modify the data when using authenticated encryption

It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio.

This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time.

[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)

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

spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected

Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error:

Unable to handle kernel NULL pointer dereference at virtual

address 0000000000000008 Call trace: complete+0x54/0x100 hisisfcv3xxisr+0x2c/0x40 [spihisisfcv3xx] _handleirqeventpercpu+0x64/0x1e0 handleirqevent+0x7c/0x1cc(CVE-2024-26776)

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

mptcp: fix double-free on socket dismantle

when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat:

BUG: KASAN: double-free in inetsockdestruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0

CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dumpstacklvl+0x32/0x50 printreport+0xca/0x620 kasanreportinvalidfree+0x64/0x90 _kasanslabfree+0x1aa/0x1f0 kfree+0xed/0x2e0 inetsockdestruct+0x54f/0x8b0 _skdestruct+0x48/0x5b0 rcudobatch+0x34e/0xd90 rcucore+0x559/0xac0 _dosoftirq+0x183/0x5a4 irqexitrcu+0x12d/0x170 sysvecapictimerinterrupt+0x6b/0x80 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x16/0x20 RIP: 0010:cpuidleenterstate+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidleenter+0x4a/0xa0 doidle+0x310/0x410 cpustartupentry+0x51/0x60 startsecondary+0x211/0x270 secondarystartup64noverify+0x184/0x18b </TASK>

Allocated by task 6853: kasansavestack+0x1c/0x40 kasansavetrack+0x10/0x30 _kasankmalloc+0xa6/0xb0 _kmalloc+0x1eb/0x450 cipsov4socksetattr+0x96/0x360 netlblsocksetattr+0x132/0x1f0 selinuxnetlblsocketpostcreate+0x6c/0x110 selinuxsocketpostcreate+0x37b/0x7f0 securitysocketpostcreate+0x63/0xb0 _sockcreate+0x305/0x450 _syssocketcreate.part.23+0xbd/0x130 _syssocket+0x37/0xb0 _x64syssocket+0x6f/0xb0 dosyscall64+0x83/0x160 entrySYSCALL64afterhwframe+0x6e/0x76

Freed by task 6858: kasansavestack+0x1c/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x12c/0x1f0 kfree+0xed/0x2e0 inetsockdestruct+0x54f/0x8b0 _skdestruct+0x48/0x5b0 subflowulprelease+0x1f0/0x250 tcpcleanupulp+0x6e/0x110 tcpv4destroysock+0x5a/0x3a0 inetcskdestroysock+0x135/0x390 tcpfin+0x416/0x5c0 tcpdataqueue+0x1bc8/0x4310 tcprcvstateprocess+0x15a3/0x47b0 tcpv4dorcv+0x2c1/0x990 tcpv4rcv+0x41fb/0x5ed0 ipprotocoldeliverrcu+0x6d/0x9f0 iplocaldeliverfinish+0x278/0x360 iplocaldeliver+0x182/0x2c0 iprcv+0xb5/0x1c0 _netifreceiveskbonecore+0x16e/0x1b0 processbacklog+0x1e3/0x650 _napipoll+0xa6/0x500 netrxaction+0x740/0xbb0 _dosoftirq+0x183/0x5a4

The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0)

The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated---(CVE-2024-26782)

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

mmc: mmci: stm32: fix DMA API overlapping mappings warning

Turning on CONFIGDMAAPIDEBUGSG results in the following warning:

DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 adddmaentry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: eventsfreezable mmcrescan Call trace: adddmaentry+0x234/0x2f4 debugdmamapsg+0x198/0x350 _dmamapsgattrs+0xa0/0x110 dmamapsgattrs+0x10/0x2c sdmmcidmaprepdata+0x80/0xc0 mmciprepdata+0x38/0x84 mmcistartdata+0x108/0x2dc mmcirequest+0xe4/0x190 _mmcstartrequest+0x68/0x140 mmcstartrequest+0x94/0xc0 mmcwaitforreq+0x70/0x100 mmcsendtuning+0x108/0x1ac sdmmcexecutetuning+0x14c/0x210 mmcexecutetuning+0x48/0xec mmcsdinituhscard.part.0+0x208/0x464 mmcsdinitcard+0x318/0x89c mmcattachsd+0xe4/0x180 mmcrescan+0x244/0x320

DMA API debug brings to light leaking dma-mappings as dmamapsg and dmaunmapsg are not correctly balanced.

If an error occurs in mmcicmdirq function, only mmcidmaerror function is called and as this API is not managed on stm32 variant, dmaunmapsg is never called in this error path.(CVE-2024-26787)

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

btrfs: dev-replace: properly validate device names

There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel().

Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later.

This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).(CVE-2024-26791)

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

btrfs: fix double free of anonymous device after snapshot creation failure

When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem.

The steps that lead to this:

1) At ioctl.c:createsnapshot() we allocate an anonymous device number and assign it to pendingsnapshot->anon_dev;

2) Then we call btrfscommittransaction() and end up at transaction.c:creatependingsnapshot();

3) There we call btrfsgetnewfsroot() and pass it the anonymous device number stored in pendingsnapshot->anondev;

4) btrfsgetnewfsroot() frees that anonymous device number because btrfslookupfs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking;

5) After that some error happens in the transaction commit path, and at ioctl.c:createsnapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pendingsnapshot->anon_dev still has the same value as in step 1.

Recently syzbot ran into this and reported the following trace:

------------[ cut here ]------------ idafree called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 idafree+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:idafree+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfsgetrootref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 creatependingsnapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 creatependingsnapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfscommittransaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 createsnapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfsmksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfsmksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 _btrfsioctlsnapcreate+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfsioctlsnapcreatev2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfsioctl+0xa74/0xd40 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:871 [inline] _sesysioctl+0xfe/0x170 fs/ioctl.c:857 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK>

Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfsgetroot_ref(), so this change may not fix the case triggered by sy ---truncated---(CVE-2024-26792)

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

Bluetooth: Avoid potential use-after-free in hcierrorreset

While handling the HCIEVHARDWAREERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hcidev and lead to a use-after-free in hcierrorreset.

Here's the call trace observed on a ChromeOS device with Intel AX201: queueworkon+0x3e/0x6c _hcicmdsyncsk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? initwaitentry+0x31/0x31 _hcicmdsync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hcierrorreset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] processonework+0x1d8/0x33f workerthread+0x21b/0x373 kthread+0x13a/0x152 ? prcontwork+0x54/0x54 ? kthreadblkcg+0x31/0x31 retfrom_fork+0x1f/0x30

This patch holds the reference count on the hcidev while processing a HCIEVHARDWAREERROR event to avoid potential crash.(CVE-2024-26801)

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

net: ip_tunnel: prevent perpetual headroom growth

syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasanreport+0xda/0x110 mm/kasan/report.c:588 _skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 skbflowdissectflowkeys include/linux/skbuff.h:1514 [inline] skbgethash net/core/flowdissector.c:1791 [inline] _skbgethash+0xc7/0x540 net/core/flowdissector.c:1856 skbgethash include/linux/skbuff.h:1556 [inline] iptunnelxmit+0x1855/0x33c0 net/ipv4/iptunnel.c:748 ipiptunnelxmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 _devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x42c/0x5d0 net/core/neighbour.c:1592 ... ipfinishoutput2+0x833/0x2550 net/ipv4/ipoutput.c:235 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 .. iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1dbc/0x33c0 net/ipv4/iptunnel.c:831 ipgrexmit+0x4a1/0x980 net/ipv4/ipgre.c:665 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 ...

The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: _skbpull(skb, skbnetworkoffset(skb));

... but skbnetworkoffset() returns a negative offset and _skbpull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.

The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around.

The bug is in the iptunnel infrastructure, which can cause dev->neededheadroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0.

2). iptunnelxmit for gre0 bumps gre0->neededheadroom based on the future output device, rt.dev->neededheadroom (ipip0).

3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion).

4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet.

tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom.

This repeats for every future packet:

gre0->neededheadroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 neededheadroom was increased.

For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k.

Once that happens, skb->networkheader (u16) wraps around when pskbexpandhead tries to make sure that skbnetwork_offset() is unchanged after the headroom expansion/reallocation.

After this skbnetworkoffset(skb) returns a different (and negative) result post headroom expansion.

The next trip to neigh layer (or anything else that would _skbpull the network header) makes skb->data point to a memory location outside skb->head area.

v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.(CVE-2024-26804)

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

netlink: Fix kernel-infoleak-after-free in _skbdatagram_iter

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

netlinktofullskb() creates a new skb and puts the skb->data passed as a 1st arg of netlinktofullskb() onto new skb. The data size is specified as len and passed to skbputdata(). This len is based on skb->end that is not data offset but buffer offset. The skb->end contains data and tailroom. Since the tailroom is not initialized when the new skb created, KMSAN detects uninitialized memory area when copying the data.

This patch resolved this issue by correct the len from skb->end to skb->len, which is the actual data offset.

BUG: KMSAN: kernel-infoleak-after-free in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copytoiter+0x364/0x2520 lib/ioviter.c:186 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+0x364/0x2520 lib/ioviter.c:186 copytoiter include/linux/uio.h:197 [inline] simplecopytoiter+0x68/0xa0 net/core/datagram.c:532 _skbdatagramiter+0x123/0xdc0 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:3960 [inline] packetrecvmsg+0xd9c/0x2000 net/packet/afpacket.c:3482 sockrecvmsgnosec net/socket.c:1044 [inline] sockrecvmsg net/socket.c:1066 [inline] sockreaditer+0x467/0x580 net/socket.c:1136 callreaditer include/linux/fs.h:2014 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x8f6/0xe00 fs/readwrite.c:470 ksysread+0x20f/0x4c0 fs/readwrite.c:613 _dosysread fs/readwrite.c:623 [inline] _sesysread fs/readwrite.c:621 [inline] _x64sysread+0x93/0xd0 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was stored to memory at: skbputdata include/linux/skbuff.h:2622 [inline] netlinktofullskb net/netlink/afnetlink.c:181 [inline] netlinkdelivertapskb net/netlink/afnetlink.c:298 [inline] _netlinkdelivertap+0x5be/0xc90 net/netlink/afnetlink.c:325 netlinkdelivertap net/netlink/afnetlink.c:338 [inline] netlinkdelivertapkernel net/netlink/afnetlink.c:347 [inline] netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x10f1/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

Uninit was created at: freepagesprepare mm/pagealloc.c:1087 [inline] freeunrefpageprepare+0xb0/0xa40 mm/pagealloc.c:2347 freeunrefpagelist+0xeb/0x1100 mm/pagealloc.c:2533 releasepages+0x23d3/0x2410 mm/swap.c:1042 freepagesandswapcache+0xd9/0xf0 mm/swapstate.c:316 tlbbatch_pages ---truncated---(CVE-2024-26805)

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

netfilter: nftchainfilter: handle NETDEV_UNREGISTER for inet/ingress basechain

Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.(CVE-2024-26808)

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

netfilter: nftsetpipapo: release elements in clone only from destroy path

Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice.

This fix requires:

212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")

which came after:

9827a0e6e23b ("netfilter: nftsetpipapo: release elements in clone from abort path").(CVE-2024-26809)

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

ksmbd: validate payload size in ipc response

If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)

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

vfio/pci: Create persistent INTx handler

A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending.

Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace.

As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irqtype configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfdsignal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)

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

vfio/fsl-mc: Block calling interrupt handler without trigger

The eventfdctx trigger pointer of the vfiofslmcirq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between requestirq() and freeirq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.

The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)

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

amdkfd: use calloc instead of kzalloc to avoid integer overflow

This uses calloc instead of doing the multiplication which might overflow.(CVE-2024-26817)

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

cifs: fix underflow in parseserverinterfaces()

In this loop, we step through the buffer and after each item we check if the sizeleft is greater than the minimum size we need. However, the problem is that "bytesleft" is type ssizet while sizeof() is type sizet. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.(CVE-2024-26828)

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

media: irtoy: fix a memleak in irtoytx

When irtoycommand fails, buf should be freed since it is allocated by irtoytx, or there is a memleak.(CVE-2024-26829)

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

IB/hfi1: Fix a memleak in initcreditreturn

When dmaalloccoherent fails to allocate dd->crbase[i].va, initcreditreturn should deallocate dd->crbase and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.(CVE-2024-26839)

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

cachefiles: fix memory leak in cachefilesaddcache()

The following memory leak was reported after unbinding /dev/cachefiles:

================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmemcachealloc+0x2d5/0x370 [<ffffffff8e917f86>] preparecreds+0x26/0x2e0 [<ffffffffc002eeef>] cachefilesdeterminecachesecurity+0x1f/0x120 [<ffffffffc00243ec>] cachefilesaddcache+0x13c/0x3a0 [<ffffffffc0025216>] cachefilesdaemonwrite+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfswrite+0xcb/0x520 [<ffffffff8ebc5069>] ksyswrite+0x69/0xf0 [<ffffffff8f6d4662>] dosyscall64+0x72/0x140

[<ffffffff8f8000aa>] entrySYSCALL64afterhwframe+0x6e/0x76

Put the reference count of cachecred in cachefilesdaemonunbind() to fix the problem. And also put cachecred in cachefilesaddcache() error branch to avoid memory leaks.(CVE-2024-26840)

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

efi: runtime: Fix potential overflow of soft-reserved region size

md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.(CVE-2024-26843)

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

nvme-fc: do not wait in vain when unloading module

The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvmedeletectrl and ida_destroy has been added by the initial commit.

There is some logic around trying to prevent from hanging forever in waitforcompletion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever.

If we completely rely on the cleanup code executed from the nvmedeletectrl path, all IDs will be freed eventually. This makes calling idadestroy unnecessary. We only have to ensure that all nvmedeletectrl code has been executed before we leave nvmefcexitmodule. This is done by flushing the nvmedeletewq workqueue.

While at it, remove the unused nvmefcwq workqueue too.(CVE-2024-26846)

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

net/ipv6: avoid possible UAF in ip6routempath_notify()

syzbot found another use-after-free in ip6routempath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in ip6routempath_notify") was not able to fix the root cause.

We need to defer the fib6inforelease() calls after ip6routempath_notify(), in the cleanup phase.

[1] BUG: KASAN: slab-use-after-free in rt6fillnode+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2e0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x167/0x540 mm/kasan/report.c:488 kasanreport+0x142/0x180 mm/kasan/report.c:601 rt6fillnode+0x1460/0x1ac0 inet6rtnotify+0x13b/0x290 net/ipv6/route.c:6184 ip6routempathnotify net/ipv6/route.c:5198 [inline] ip6routemultipathadd net/ipv6/route.c:5404 [inline] inet6rtmnewroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>

Allocated by task 23037: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:372 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:389 kasankmalloc include/linux/kasan.h:211 [inline] _dokmallocnode mm/slub.c:3981 [inline] _kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6infoalloc+0x2e/0xf0 net/ipv6/ip6fib.c:155 ip6routeinfocreate+0x445/0x12b0 net/ipv6/route.c:3758 ip6routemultipathadd net/ipv6/route.c:5298 [inline] inet6rtmnewroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

Freed by task 16: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x4e/0x60 mm/kasan/generic.c:640 poisonslab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)

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

net: ice: Fix potential NULL pointer dereference in icebridgesetlink()

The function icebridgesetlink() may encounter a NULL pointer dereference if nlmsgfindattr() returns NULL and brspec is dereferenced subsequently in nlaforeachnested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)

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

net/bnx2x: Prevent access to a freed page in page_pool

Fix race condition leading to system crash during EEH error handling

During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2xtxtimeout() schedules reset tasks via bnx2xsprtnltask(), which ultimately leads to bnx2xnicunload(). In bnx2xnicunload() SGEs are freed using bnx2xfreerxsgerange(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2xioslotreset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2xfreerx_sge()

799 static inline void bnx2xfreerxsge(struct bnx2x *bp, 800 struct bnx2xfastpath *fp, u16 index) 801 { 802 struct swrxpage *swbuf = &fp->rxpagering[index]; 803 struct page *page = swbuf->page; .... where swbuf was set to NULL after the call to dmaunmap_page() by the preceding thread.

EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64

To solve this issue, we need to verify page pool allocations before freeing.(CVE-2024-26859)

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

packet: annotate data-races around ignore_outgoing

ignoreoutgoing is read locklessly from devqueuexmitnit() and packet_getsockopt()

Add appropriate READONCE()/WRITEONCE() annotations.

syzbot reported:

BUG: KCSAN: data-race in devqueuexmitnit / packetsetsockopt

write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packetsetsockopt+0xd83/0xfd0 net/packet/afpacket.c:4003 dosocksetsockopt net/socket.c:2311 [inline] _syssetsockopt+0x1d8/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0x66/0x80 net/socket.c:2340 dosyscall64+0xd3/0x1d0 entrySYSCALL64after_hwframe+0x6d/0x75

read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: devqueuexmitnit+0x82/0x620 net/core/dev.c:2248 xmitone net/core/dev.c:3527 [inline] devhardstartxmit+0xcc/0x3f0 net/core/dev.c:3547 _devqueuexmit+0xf24/0x1dd0 net/core/dev.c:4335 devqueuexmit include/linux/netdevice.h:3091 [inline] batadvsendskbpacket+0x264/0x300 net/batman-adv/send.c:108 batadvsendbroadcastskb+0x24/0x30 net/batman-adv/send.c:127 batadvivogmsendtoif net/batman-adv/bativogm.c:392 [inline] batadvivogmemit net/batman-adv/bativogm.c:420 [inline] batadvivsendoutstandingbatogmpacket+0x3f0/0x4b0 net/batman-adv/bativogm.c:1700 processonework kernel/workqueue.c:3254 [inline] processscheduledworks+0x465/0x990 kernel/workqueue.c:3335 workerthread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 retfromfork+0x4b/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:243

value changed: 0x00 -> 0x01

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: batevents batadvivsendoutstandingbatogm_packet(CVE-2024-26862)

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

hsr: Fix uninit-value access in hsrgetnode()

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

===================================================== BUG: KMSAN: uninit-value in hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 fillframeinfo net/hsr/hsrforward.c:577 [inline] hsrforwardskb+0xe12/0x30e0 net/hsr/hsrforward.c:615 hsrdevxmit+0x1a1/0x270 net/hsr/hsrdevice.c:223 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3087 [inline] packetsendmsg+0x8b1d/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 _allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2787 packetallocskb net/packet/afpacket.c:2936 [inline] packetsnd net/packet/afpacket.c:3030 [inline] packetsendmsg+0x70e8/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

If the packet type ID field in the Ethernet header is either ETHPPRP or ETHPHSR, but it is not followed by an HSR tag, hsrgetskbsequencenr() reads an invalid value as a sequence number. This causes the above issue.

This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.(CVE-2024-26863)

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

rds: tcp: Fix use-after-free of net in reqsktimerhandler().

syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].

syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:

18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)

The notable thing here is 0x4001 in connect(), which is RDSTCPPORT.

So, the scenario would be:

1. unshare(CLONENEWNET) creates a per netns tcp listener in rdstcplisteninit().
2. syz-executor connect()s to it and creates a reqsk.
3. syz-executor exit()s immediately.
4. netns is dismantled. [0]
5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]
6. listener is freed after RCU grace period. [2]

Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets.

Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inettwskpurge()") fixed this issue only for per-netns ehash.

Let's apply the same fix for the global ehash.

 sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
 inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
 __sock_create (net/socket.c:1572)
 rds_tcp_listen_init (net/rds/tcp_listen.c:279)
 rds_tcp_init_net (net/rds/tcp.c:577)
 ops_init (net/core/net_namespace.c:137)
 setup_net (net/core/net_namespace.c:340)
 copy_net_ns (net/core/net_namespace.c:497)
 create_new_namespaces (kernel/nsproxy.c:110)
 unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
 ksys_unshare (kernel/fork.c:3429)
 __x64_sys_unshare (kernel/fork.c:3496)
 do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)

... WARNING: CPU: 0 PID: 27 at lib/reftracker.c:179 reftrackerdirexit (lib/ref_tracker.c:179)

Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:107 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) kasanreport (mm/kasan/report.c:603) inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) reqsktimerhandler (net/ipv4/inetconnectionsock.c:979 net/ipv4/inetconnectionsock.c:1092) calltimerfn (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) _runtimers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) runtimersoftirq (kernel/time/timer.c:2053) _dosoftirq (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irqexitrcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvecapictimer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ>

Allocated by task 258 on cpu 0 at 83.612050s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) _kasanslaballoc (mm/kasan/common.c:343) kmemcachealloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copynetns (./include/linux/slab.h:701 net/core/netnamespace.c:421 net/core/netnamespace.c:480) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxy_name ---truncated---(CVE-2024-26865)

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

f2fs: fix to truncate meta inode pages forcely

Below race case can cause data corruption:

Thread A GC thread - gcdatasegment - radatablock - locked metainode page - f2fsinplacewritedata - invalidatemappingpages : fail to invalidate metainode page due to lock failure or dirty|writeback status - f2fssubmitpagebio : write last dirty data to old blkaddr - movedatablock - load old data from metainode page - f2fssubmitpagewrite : write old data to new blkaddr

Because invalidatemappingpages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncateinodepagesrange() instead of invalidatemappingpages() to make sure metainode page will be dropped.(CVE-2024-26869)

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

NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102

A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4listxattr() does not return an error because either genericlistxattr() or nfs4listxattrnfs4label() consumes exactly all the bytes then size is 0 when calling nfs4listxattrnfs4user() which then triggers the following kernel BUG:

[ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopyabort+0x70/0xa0 [ 99.416227] _checkheapobject+0x134/0x158 [ 99.416505] checkheapobject+0x150/0x188 [ 99.416696] _checkobjectsize.part.0+0x78/0x168 [ 99.416886] _checkobjectsize+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] pathlistxattr+0x78/0xe0 [ 99.417476] _arm64syslistxattr+0x28/0x40 [ 99.417723] invokesyscall+0x78/0x100 [ 99.417929] el0svccommon.constprop.0+0x48/0xf0 [ 99.418186] doel0svc+0x24/0x38 [ 99.418376] el0svc+0x3c/0x110 [ 99.418554] el0t64synchandler+0x120/0x130 [ 99.418788] el0t64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)

Issue is reproduced when genericlistxattr() returns 'system.nfs4acl', thus calling lisxattr() with size = 16 will trigger the bug.

Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size.(CVE-2024-26870)

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

RDMA/srpt: Do not register event handler until srpt device is fully setup

Upon rare occasions, KASAN reports a use-after-free Write in srptrefreshport().

This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place.

Instead, only register the event handler after srpt device initialization is complete.(CVE-2024-26872)

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

media: pvrusb2: fix uaf in pvr2contextset_notify

[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextset_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] _kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.

[Fix] Place the disconnectflag assignment operation after all code in pvr2context_disconnect() to avoid this issue.(CVE-2024-26875)

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

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

P1 P2 dquotfreeinode quotaoff dropdquotref removedquotref dquots = idquot(inode) dquots = idquot(inode) srcureadlock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spinlock(&dquots[cnt]->dqdqblock) (3) ....

If dquotfreeinode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)

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

dm: call the resume method on internal suspend

There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the originpostsuspend function. The second call attempts to remove the "hashlist" entry from a list, while it was already removed by the first call.

Fix _dminternal_resume so that it calls the preresume and resume methods of the table's targets.

If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dminternalresume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash.

------------[ cut here ]------------ kernel BUG at lib/listdebug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:listdelentryvalidorreport+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? dotrap+0xeb/0xf0 ? _listdelentryvalidorreport+0x77/0xc0 ? doerrortrap+0x60/0x80 ? _listdelentryvalidorreport+0x77/0xc0 ? excinvalidop+0x49/0x60 ? _listdelentryvalidorreport+0x77/0xc0 ? asmexcinvalidop+0x16/0x20 ? tabledeps+0x1b0/0x1b0 [dmmod] ? _listdelentryvalidorreport+0x77/0xc0 originpostsuspend+0x1a/0x50 [dmsnapshot] dmtablepostsuspendtargets+0x34/0x50 [dmmod] dmsuspend+0xd8/0xf0 [dmmod] devsuspend+0x1f2/0x2f0 [dmmod] ? tabledeps+0x1b0/0x1b0 [dmmod] ctlioctl+0x300/0x5f0 [dmmod] dmcompatctlioctl+0x7/0x10 [dmmod] _x64compatsysioctl+0x104/0x170 dosyscall64+0x184/0x1b0 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]---(CVE-2024-26880)

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

firmware: arm_scmi: Fix double free in SMC transport cleanup path

When the generic SCMI code tears down a channel, it calls the chanfree callback function, defined by each transport. Since multiple protocols might share the same transportinfo member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time:

| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
|   ESR = 0x0000000096000004
|   EC = 0x25: DABT (current EL), IL = 32 bits
|   SET = 0, FnV = 0
|   EA = 0, S1PTW = 0
|   FSC = 0x04: level 0 translation fault
| Data abort info:
|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
| Hardware name: FVP Base RevC (DT)
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : smc_chan_free+0x3c/0x6c
| lr : smc_chan_free+0x3c/0x6c
| Call trace:
|  smc_chan_free+0x3c/0x6c
|  idr_for_each+0x68/0xf8
|  scmi_cleanup_channels.isra.0+0x2c/0x58
|  scmi_probe+0x434/0x734
|  platform_probe+0x68/0xd8
|  really_probe+0x110/0x27c
|  __driver_probe_device+0x78/0x12c
|  driver_probe_device+0x3c/0x118
|  __driver_attach+0x74/0x128
|  bus_for_each_dev+0x78/0xe0
|  driver_attach+0x24/0x30
|  bus_add_driver+0xe4/0x1e8
|  driver_register+0x60/0x128
|  __platform_driver_register+0x28/0x34
|  scmi_driver_init+0x84/0xc0
|  do_one_initcall+0x78/0x33c
|  kernel_init_freeable+0x2b8/0x51c
|  kernel_init+0x24/0x130
|  ret_from_fork+0x10/0x20
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
| ---[ end trace 0000000000000000 ]---

Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation.

This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)

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

wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces

wilcnetdevcleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver:

echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind

================================================================== BUG: KASAN: slab-use-after-free in wilcnetdevcleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86

CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x58 dumpstacklvl from printreport+0x154/0x500 printreport from kasanreport+0xac/0xd8 kasanreport from wilcnetdevcleanup+0x508/0x5cc wilcnetdevcleanup from wilcbusremove+0xc8/0xec wilcbusremove from spiremove+0x8c/0xac spiremove from devicereleasedriverinternal+0x434/0x5f8 devicereleasedriverinternal from unbindstore+0xbc/0x108 unbindstore from kernfsfopwriteiter+0x398/0x584 kernfsfopwriteiter from vfswrite+0x728/0xf88 vfswrite from ksyswrite+0x110/0x1e4 ksyswrite from retfast_syscall+0x0/0x1c

[...]

Allocated by task 1: kasansavetrack+0x30/0x5c _kasankmalloc+0x8c/0x94 _kmallocnode+0x1cc/0x3e4 kvmallocnode+0x48/0x180 allocnetdevmqs+0x68/0x11dc allocetherdevmqs+0x28/0x34 wilcnetdevifcinit+0x34/0x8ec wilccfg80211init+0x690/0x910 wilcbusprobe+0xe0/0x4a0 spiprobe+0x158/0x1b0 reallyprobe+0x270/0xdf4 _driverprobedevice+0x1dc/0x580 driverprobedevice+0x60/0x140 _driverattach+0x228/0x5d4 busforeachdev+0x13c/0x1a8 busadddriver+0x2a0/0x608 driverregister+0x24c/0x578 dooneinitcall+0x180/0x310 kernelinitfreeable+0x424/0x484 kernelinit+0x20/0x148 retfromfork+0x14/0x28

Freed by task 86: kasansavetrack+0x30/0x5c kasansavefreeinfo+0x38/0x58 _kasanslabfree+0xe4/0x140 kfree+0xb0/0x238 devicerelease+0xc0/0x2a8 kobjectput+0x1d4/0x46c netdevruntodo+0x8fc/0x11d0 wilcnetdevcleanup+0x1e4/0x5cc wilcbusremove+0xc8/0xec spiremove+0x8c/0xac devicereleasedriverinternal+0x434/0x5f8 unbindstore+0xbc/0x108 kernfsfopwriteiter+0x398/0x584 vfswrite+0x728/0xf88 ksyswrite+0x110/0x1e4 retfastsyscall+0x0/0x1c [...]

David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needsfreenetdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list.

Fix this use-after-free thanks to two mechanisms: - navigate in the list with listforeachentrysafe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with listdelrcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev)

Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vifmutex lock), we do not need to use RCU list API, that's why we can benefit from listforeachentry_safe.

[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/(CVE-2024-26895)

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

wifi: wfx: fix memory leak when starting AP

Kmemleak reported this error:

unreferenced object 0xd73d1180 (size 184):
  comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00  ................
  backtrace:
    [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
    [<127bdd74>] __alloc_skb+0x144/0x170
    [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
    [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
    [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
    [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
    [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
    [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
    [<47bd8b68>] genl_rcv_msg+0x198/0x378
    [<453ef796>] netlink_rcv_skb+0xd0/0x130
    [<6b7c977a>] genl_rcv+0x34/0x44
    [<66b2d04d>] netlink_unicast+0x1b4/0x258
    [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
    [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
    [<d2b5212d>] ___sys_sendmsg+0x80/0xb4
    [<69954f45>] __sys_sendmsg+0x64/0xa8
unreferenced object 0xce087000 (size 1024):
  comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
  backtrace:
    [<9a993714>] __kmalloc_track_caller+0x230/0x600
    [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
    [<a2c61343>] __alloc_skb+0xa0/0x170
    [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
    [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
    [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
    [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
    [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
    [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
    [<47bd8b68>] genl_rcv_msg+0x198/0x378
    [<453ef796>] netlink_rcv_skb+0xd0/0x130
    [<6b7c977a>] genl_rcv+0x34/0x44
    [<66b2d04d>] netlink_unicast+0x1b4/0x258
    [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
    [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
    [<d2b5212d>] ___sys_sendmsg+0x80/0xb4

However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfxsetmfpap(). The issue is obvious in this function: memory allocated by ieee80211beacon_get() is never released. Fixing this leak makes kmemleak happy.(CVE-2024-26896)

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

wifi: ath9k: delay all of ath9kwmievent_tasklet() until init is complete

The ath9kwmieventtasklet() used in ath9khtc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed.

We already committed a partial fix for this in commit: 8b3046abc99e ("ath9khtc: fix NULL pointer dereference at ath9khtctxget_packet()")

However, that commit only aborted the WMITXSTATUSEVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9khtcprobedevice() instead of inside ath9ktx_init()).(CVE-2024-26897)

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

scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"

This reverts commit 1a1975551943f681772720f639ff42fbaa746212.

This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".

Instead, a work queue should be used, and will be addressed in a separate commit.(CVE-2024-26917)

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

inet: inet_defrag: prevent sk release while still in use

iplocalout() and other functions can pass skb->sk as function argument.

If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.

This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.

Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ipdefrag() in output path is also implying skborphan(), which is buggy because output path relies on sk not disappearing.

A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")

[..]

net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.

If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.

We need to change ipdefrag() to only use skborphan() when really needed, ie whenever frag_list is going to be used.

Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:

If skb is refragmented again right after, ipdofragment() will copy head->sk to the new fragments, and sets up destructor to sockwfree. IOW, we have no choice but to fix up skwmem accouting to reflect the fully reassembled skb, else wmem will underflow.

This change moves the orphan down into the core, to last possible moment. As ipdefragoffset is aliased with skbuff->sk member, we must move the offset into the FRAGCB, else skb->sk gets clobbered.

This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.

In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.

In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)

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

drm/amdgpu: validate the parameters of bo mapping operations more clearly

Verify the parameters of amdgpuvmbo(map/replacemap/clearing_mappings) in one common place.(CVE-2024-26922)